181 replies to this topic

[LinktheMaster]

If you have the "Skip Continue Screen" quest rule enabled, if you go to Game->End Game, it abruptly kicks you out of the quest with no warning. Personally, I think this should bring up a popup that says something like "Warning: This will close out of your current game, not allowing you to save." Another option would be to disable the End Game menu option, forcing people to use reset (which already gives a popup warning). Personally, I figured the first option would be better.

[Saffith]

Yeah, it could do with a bit more warning. Probably needs to be a separate dialog; I know a lot of people just rush through the existing confirmation.

Even if by some miracle it worked well enough to play through a quest without crashing the FPS would actually be much worse than it is already, because you're not really changing CPU to GPU, it's just adding it on at the end through a bunch of hacks really.

Ah. Well, that's disappointing...

[Timelord]

I'm the one who handles the Linux builds.
The difference in speed comes from Allegro; it's using DirectX on Windows and software rendering on Mac and Linux. There's an add-on that allows it to use OpenGL, but attempts to use it have not gone well so far. I'll probably give it another try before we're done, though. I will at least be using profile-guided optimization for future builds.

Sounds good. I thought it would be a HW issue that I'd need to debug with my configuration, so now I know that there's essentially nothing I can do about it, and just deal with it. Would a frame-skip option help this at all?

PPC used to be supported, and it's still possible, as far as I know. I'll have to ask _L_ about it.

Yeah, people assume that everyone just jumps on Apple's latest bandwagon. When you have $7,500 invested in hardware, you don't upgrade for a while. I have two Dual-G5 systems, so those are my main GFX and DTP workstations. I would hope they have the guts needed to run it, but with the choppy graphical issues on the Linux version, it's likely to be the same on PPC OSX, although perhaps there are better facilities available for the platform.

The whole file's encrypted. Meant to prevent cheating, I suppose.

I guess I can see that. It just causes little problems like this... If the 'Game genie' taught us anything, it is that people who want to cheat will always find a way. If this wasn't already so easily fixed, I'd suggest encrypting the quest data in the file, stored as ASCII, decrypted by the quest password, but leaving the rest of it such as file pointers open. This way, the actual .sav file need not be encrypted, but the data stored by each game would be instead. that way, it would also be possible for questmakers to set this to be open and permit manual modification if they desire.

Anyhow, if you end up finding a way around the speed issue, that'd be awesome. No worries either way.

P.S. I honestly have issues with that kind of quest rule. As I understand it, that prevents you from saving unless you die, correct? I would never do that to a player... I have never tried enabling it, but from what I gathered, it just sounds obnoxious.

Edited by ZoriaRPG, 08 February 2012 - 01:56 PM.

[Kite]

P.S. I honestly have issues with that kind of quest rule. As I understand it, that prevents you from saving unless you die, correct? I would never do that to a player... I have never tried enabling it, but from what I gathered, it just sounds obnoxious.

The reason people use that quest rule is simple: save/continue management.

While I don't doubt there would probably be people sadistic enough to never allow people to save or continue, most people use the quest rule so that they can use ZC's save point system or manage saving through scripting. This allows the quest builder to keep the player from saving and/or continuing during unwanted times.

[blue_knight]

The reason people use that quest rule is simple: save/continue management.

While I don't doubt there would probably be people sadistic enough to never allow people to save or continue, most people use the quest rule so that they can use ZC's save point system or manage saving through scripting. This allows the quest builder to keep the player from saving and/or continuing during unwanted times.

I use that rule to manage saving myself in my quests, actually.

[Timelord]

The reason people use that quest rule is simple: save/continue management.

While I don't doubt there would probably be people sadistic enough to never allow people to save or continue, most people use the quest rule so that they can use ZC's save point system or manage saving through scripting. This allows the quest builder to keep the player from saving and/or continuing during unwanted times.

I guess I just haven't seen it demonstrated properly, or had it correctly explained to me, in terms of what it is and does and why it is there. I thought I recalled it being used to prevent the fast-continue thing that so many people like to exploit, which I have only done in places where there was an actual bug that prevented progressing normally--well, I did it once when there was no bug, but I thought there was and I later went back to verify and figured out what I had missed--so if it has a critical function, I was not aware of that. Is there a good demonstration of it in use that you can suggest viewing or reading?

I am going to set my quest to resume from continue with minimum hearts though, as per the original game and TotG/LttP. I can understand using it to escape bug, or to save and later resume, but using it to jump around to avoid parts of dungeons is just nonsense to me.

If it is mandatory for some of the scripting, I will likely end up using it, but that will come later. I don't want to do too much more before RC3 is ready, and it's going to be a long road, being near the bottom of my to-do list each day/week/aeon. I think that when it is ready, some people will be pleased, and others will hate it, for one reason or another. Aside from using the engine, my story has nothing to do with the Zelda storyline(s), but should be enjoyable for that reason. It is going to be very story-heavy adventure though, and not extremely difficult, which will be a turn-off to some players as well.

The entire point is to tell a story inside the game, and to introduce some of what I'm doing to more people. This is why I am hoping to replace the item-collection events, and do some other crazy stuff. I really like some of the side-scrolling room demos that I've seen as well, and plan to make use of those; (keep in mind that this is 1+ years from being done, unless I hit the lottery). I would also like to see some good demos of the enemy editor at some point, so if anyone can suggest some videos for that, as I will be making use of it, which I can hopefully achieve without tonnes of custom scripts for bosses, I would very much a-lot appreciate it.

[Red Phazon]

I guess I just haven't seen it demonstrated properly, or had it correctly explained to me, in terms of what it is and does and why it is there. I thought I recalled it being used to prevent the fast-continue thing that so many people like to exploit, which I have only done in places where there was an actual bug that prevented progressing normally--well, I did it once when there was no bug, but I thought there was and I later went back to verify and figured out what I had missed--so if it has a critical function, I was not aware of that. Is there a good demonstration of it in use that you can suggest viewing or reading?

If you've played Skyward Sword yet, the quest rule plus save combos make for a similar system. You are only meant to save at certain locations. One good thing about this is that continue bugs seem less likely.

Anyway, you sound very ambitious and I hope to play a quest from you eventually.

[Gleeok]

Ah. Well, that's disappointing...

Yeah. I don't know if it works better on Linux though. Main problem is no 8-bit or palette color support. I've used AGL once before and it worked fine using only OpenGL API. So yeah, just trying to "get it to work", which is what I tried a while back, is a bad idea. Though if tiles and fonts were loaded as texture atlas's, palettes were rewritten as GLSL, no allegro gfx api (or BITMAPS) was actually used.... eh nvrmnd. (Just get RC3 out quick. )

[blue_knight]

Yeah. I don't know if it works better on Linux though. Main problem is no 8-bit or palette color support. I've used AGL once before and it worked fine using only OpenGL API. So yeah, just trying to "get it to work", which is what I tried a while back, is a bad idea. Though if tiles and fonts were loaded as texture atlas's, palettes were rewritten as GLSL, no allegro gfx api (or BITMAPS) was actually used.... eh nvrmnd. (Just get RC3 out quick. )

If it were me, I'd still have a basic 320x240 software rendering path but use OpenGL to do the final screen blitting. This would allow you to run at native resolution, run in full color and support arbitrary resolutions with excellent performance but still support systems with really low-end GPU's. In order to emulate palettes using GLSL, you really need Radeon 9500+ or NVida 6x000 series or better for good performance - ancient by today's standards but probably still too new for some ZC users (though I could be wrong). Of course full GPU support would be a good option for systems that support it of course. Being able to run the editor at full desktop resolutions would be awesome.

[Timelord]

That's on of those 'Ancient, to whom?' issues. They are on par with, or in excess of any GPU that I use, as I do not play normal computer games that would require them. The only programme I use that does is MAME, and that is for screen effects. Thus, having more is superfluous, and of course, in the case of portable hardware, impossible.

One would hope that ZC would run at lest reasonably well on light hardware, or old hardware, as it doesn't need super-high-performance for rendering.

As to what I'm working on... My plans are always ambitions, no-matter the subject. I feel that if I am going to work on anything, I'm going to give it my all and make it as nice and interesting as I may. I don't much see the point in dedicating my time to making something small or basic, as I will learn what I need to learn by tacking the bigger fish, and in the process, come up with something truly interesting. The story will be based on my original work, and the items will get tweaks, and there will be some twists and surprises along the way, but I don't want it to be one of those hell-quests.

I tried to play some of those, and found them utterly un-enjoyable, however games such as 'Souls of Wisdom' and 'Lost Isle' are just about right for me.

[LinktheMaster]

One would hope that ZC would run at lest reasonably well on light hardware, or old hardware, as it doesn't need super-high-performance for rendering.

From what I can tell through testing and such, ZC 2.50 seems to be able to maintain a solid 60 FPS normally with at least approximately a 1GHz processor core on Windows. That's my estimate, at least. Netbooks seem to run 2.5 at around 50FPs, but the Atom processors in them have hyperthreading, so since ZC doesn't support multithreading, essentially halves the usable processing power to around 800MHz. I think around a 1.5GHz core should be able to run just about anything 2.50 related goes with no troubles (including heavy scripted quests like blue_knight's World Tree and his 3D quest).

That's what I gather from hearing about slow down issues from people (mostly Nick and Rover). Nick has a dual core processor that has been slowed down to around 1.4GHz. It works find on quests with basic scripting, but slows down on heavily scripted quests. Rover has a netbook (presumably with a 1.66GHz Atom processor) that gets 50FPS on a regular 2.5 quest with no scripting.

Of course, this is on Windows. Dunno how that compares to Linux and Mac builds.

[blue_knight]

That's on of those 'Ancient, to whom?' issues. They are on par with, or in excess of any GPU that I use, as I do not play normal computer games that would require them. The only programme I use that does is MAME, and that is for screen effects. Thus, having more is superfluous, and of course, in the case of portable hardware, impossible.

One would hope that ZC would run at lest reasonably well on light hardware, or old hardware, as it doesn't need super-high-performance for rendering.

As to what I'm working on... My plans are always ambitions, no-matter the subject. I feel that if I am going to work on anything, I'm going to give it my all and make it as nice and interesting as I may. I don't much see the point in dedicating my time to making something small or basic, as I will learn what I need to learn by tacking the bigger fish, and in the process, come up with something truly interesting. The story will be based on my original work, and the items will get tweaks, and there will be some twists and surprises along the way, but I don't want it to be one of those hell-quests.

I tried to play some of those, and found them utterly un-enjoyable, however games such as 'Souls of Wisdom' and 'Lost Isle' are just about right for me.

This is why I made the suggestion that I did. If one of my quests, for example, is too script heavy for your computer then you have the option of playing other quests. However if the program itself is limited to hardware that you don't have access to - then it's completely useless. That's how I see it anyway. So supporting old systems, even if they aren't fast enough for all the quests people may make, seems like the best option. However allowing the program to use better hardware to improve things even more when available is always a good idea - assuming it's worth the time/complexity/benefit trade-off of course.

[Timelord]

Aye. The only Intel-based machine I have set-up at present is an Atom-based unit. I have a tower as well, but it is dis-configured until I make more space.

How hard would it be to support hyperthreading? I presume the legacy portions of code prevent this?

(Obviously, something for the future.)

[Gleeok]

If it were me, I'd still have a basic 320x240 software rendering path but use OpenGL to do the final screen blitting. This would allow you to run at native resolution, run in full color and support arbitrary resolutions with excellent performance but still support systems with really low-end GPU's.

That was the original idea. Now getting allegro, zc, and opengl to cooperate with each other is another story.


It might work better on Mac or Linux though. Who knows. ..Heck AGL might simply have some buggy flags that were causing problems on windows. I don't know. This was a few years back so I'm really fuzzy on the details.

[LinktheMaster]

Aye. The only Intel-based machine I have set-up at present is an Atom-based unit. I have a tower as well, but it is dis-configured until I make more space.

How hard would it be to support hyperthreading? I presume the legacy portions of code prevent this?

(Obviously, something for the future.)

Well, an alternative would be to disable hyperthreading. I think on some computers you can actually do that through the BIOS. But, of course, that would hurt using other programs.

As far as supporting hyperthreading, to get much of a benefit, it would actually be difficult. Gleeok and Saffith may be able to correct me on this, but right now ZC is running on an old version of allegro. And by old, I mean ancient. It's a version that was released well before multiple cores and hyperthreading were becoming mainstream. I think the version of allegro we're using is even custom compiled because of some issues ZC had forever ago, making ZC even more dependent on that version of allegro. So essentially the version of allegro ZC uses doesn't support hyperthreading. I'm not even sure if the newest one does.

The newest version of allegro is completely different. And I mean completely different. And unfortunately I believe ZC doesn't have a "wrapper" so to speak for the language. (I'm not sure if there's a technical term for it, but basically it doesn't set aside a specific area to interpret video/audio libraries, which would make porting to different libraries easier.) Because of that, allegro calls are sprinkled throughout ZC's source code, so upgrading ZC would take quite a long time.

Of course, they could integrate multi-threading into ZC itself, but that wouldn't really help much. I'm pretty certain that allegro is 80% of the processing usage for ZC. Allegro, simply put, is a resource whore. Out of curiosity, I've used ASEPRITE, an allegro-based sprite editor that uses a much newer version of Allegro. Guess what it does? It uses exactly 25% of my processing power. No more, no less. I have a quad core AMD processor. I'm not sure if the program uses the newest version of Allegro, but my point is that Allegro is the main issue here.

So really, the best way for ZC to run better on slower computers would be to switch away from Allegro. But... that's a lot of work, and won't be thought of until after the release of ZC 2.5 at least. I do think it needs to be done, though, but I'm not a ZC dev.