i think that limits should be bigger for options:
- gems to collect up to 9999
- bigger levels (up to square 256x256!)
- options: score for collection, smashing; magic ball delay, score for each 1 second/step left, amoeba speed, magic wall duration and other options which have the limit up to 255, may be increased up to 999
- number of magic ball or yam yam contents up to 255!
- 6-digit score
other ideas :
- 2 new objects for dx bd section: frozen life and glue
- new option for bd diamond: bonus points for collecting
Bigger levels might not be too bad, now that computers are getting faster
However, it might be a better idea if everybody didn't start using them once they were possible, because some people would have an awfully hard time running them on their old computers.
Daniel H. wrote:However, it might be a better idea if everybody didn't start using them once they were possible, because some people would have an awfully hard time running them on their old computers.
Not to mention loading the tapes, even on pretty modern machines...
Well, the snakebite levels 28 & 30 are unplayable on my current PC because of the 128x128 map size, nevermind loading a tape!
*afterthought*
But why are they? The view-port is still only 17x17 so only a tiny part of the map is drawn. There also isn't a lot of moving objects in both levels and are mainly made of bricks.
Speaking about speed loss..... In both Pacman and Zelda it slows down by about 50% all because of the CE_value walls. If I change the maze in Pacman and the rooms edges in Zelda to normal walls, it runs perfectly.
Alan wrote:Speaking about speed loss..... In both Pacman and Zelda it slows down by about 50% all because of the CE_value walls. If I change the maze in Pacman and the rooms edges in Zelda to normal walls, it runs perfectly.
Well, I'm not so "inside" the code, but it should be quite logical.
All frames involve checking all the elements that, in some way, could experience a change. More the elements, more lines of code to be executed, even if it is just to know that there is nothing to do with that element in that particular frame.
I could be far too wrong with that, Holger will bring some light for sure.
Normal CEs walls without ce_value animation are ok....so I'm not so sure.
This reminds me of Rockford in Space from BD2K3.....this slowed down a bit because of all that animation going on.
But the difference is the walls in Pacman and Zelda aren't animating, so I think they are getting updated all the time, even if they don't have to. Maybe there's no way around it, and I'll have to by a new PC
Usually, every time you run RnD with, Emerald Mine Club, levels, sounds and
others that can be used in RnD; Do the Left-Crtl, Left-Alt and Delete, and
you'll see the process that have "rocksndiaomnds.exe"... Just search it
through and see the Mem. (memory) useage...
Mine has over 70mb of mem. useage, wondering if those features (mostly the
level size idea) could handle the pressure of it...
Tomi wrote:Even if you have 128x128 level filled with *empty space* (no moving, animation, or CE values), it still slows down! I wonder why.
That's curious. Seems like the engine checks all the tiles, looking for some element that could change/move...
Maybe using some kind of container to hold just the active elements and then checking just them, for each frame, it could be all faster.
But it would also mess up the whole engine scan concept, I fear, and that would need a complete rewrite of all the engine.
Even if we accept such a time-expensive rewrite, what if such a method brings the need for a lot of cross-checks? The solution could be worse than the problem.
I am reasoning for concepts, of course. I have just a cloudy idea about the way it actually works, so I could be completely wrong with that.
One thing is sure: a new tape format (which hopefully is about to come) could allow instant restore, so we shouldn't care so much about the speed of the traditional frame-by-frame reloading.
About options that are limited to 0-255: Yes, I could exted these to 0-999. In earlier versions, these values were stored in single bytes (limiting the values to 0-255), but the current version already uses two-byte values anyway (giving a number range of 0-65535).
> Bigger levels might not be too bad, now that computers are getting faster
This would be possible, yes. Although one reason for the 128x128 limitation was computation speed of the playfield, the main reason is that IMHO there is no real need for a bigger playfield, as larger levels are not necessarily better levels. If somebody disagrees here or has good use for larger levels than currently possible, let me know! Technically, it shouldn't be too big of a problem. :-)
> Not to mention loading the tapes, even on pretty modern machines...
That's right. As the game engine is quite complex, loading levels with large playfields takes quite some time. Probably there's still room for optimizations, though...
> Hopefully, Holger should implement something to make loading tapes
> faster.
As most tape loading is done for levels that are just being played (for example, when you die very often in a hard level and reload your last saved tape from the same level), there will be a solution in R'n'D 3.2.2 for reloading tapes for the current level in zero time -- I was forced to invent this to finally solve Alan Bond's "Zelda"! :-)
> Well, the snakebite levels 28 & 30 are unplayable on my current PC
> because of the 128x128 map size, nevermind loading a tape!
Yes, I know this problem... :-/
> But why are they? The view-port is still only 17x17 so only a tiny part of
> the map is drawn. There also isn't a lot of moving objects in both levels
> and are mainly made of bricks.
The time needed for drawing (especially when scrolling) is a different problem than the CPU cycles needed to scan the playfield, which is done regardless of that portion of the playfield being visible or not. It also depends a bit on levels being either build from standard walls or CE walls, as the latter are also checked for properties that standard walls cannot have.
But you are right that the game engine needs some profiling, and I'm sure that it can be made quite a bit faster than it is now.
> Speaking about speed loss..... In both Pacman and Zelda it slows down
> by about 50% all because of the CE_value walls. If I change the maze in
> Pacman and the rooms edges in Zelda to normal walls, it runs perfectly.
Yes, this is another known issue. The problem is that the graphics engine (not game engine) checks whether a playfield tile is animated or not, and currently it assumes that all tiles with a number of frames larger than one need to be redrawn every single frame (if the delay time is also one). This is not true for the "ce_value" style animation, so this can be considered a (performance related) bug that should be fixed.
> All frames involve checking all the elements that, in some way, could
> experience a change. More the elements, more lines of code to be
> executed, even if it is just to know that there is nothing to do with that
> element in that particular frame.
That's exactly the reason for the performance problem of larger levels.
But I'm sure that it can at least be optimized a bit more...
> This reminds me of Rockford in Space from BD2K3.....this slowed down
> a bit because of all that animation going on.
Yeah! That's a good example of a level where the whole display really needs to be redrawn every single frame!
> Mine has over 70mb of mem. useage, wondering if those features
> (mostly the level size idea) could handle the pressure of it...
Most memory is used for internally storing artwork bitmaps of various sizes. Extending the maximum playfield from 128x128 to 256x256 will add a few more megabytes, which should not hurt too much on current systems.
But the minimal system requirements for smoothly running R'n'D are already far to high for this kind of game... :-/
> Even if you have 128x128 level filled with *empty space* (no moving,
> animation, or CE values), it still slows down! I wonder why.
Because there are far too many checks and calculations even on an empty playfield. :-/
> Maybe using some kind of container to hold just the active elements and
> then checking just them, for each frame, it could be all faster.
Yes, but you have to update that container every frame, which can be tricky (you would have to do it "on the fly" to prevent an additional full playfield scan every frame).
In fact, the engine already does something like that by using a property "inactive" to immediately skip, for example, empty elements. It still needs to much time even on empty levels, though...
> One thing is sure: a new tape format (which hopefully is about to come)
> could allow instant restore, so we shouldn't care so much about the
> speed of the traditional frame-by-frame reloading.
This is independent of the tape format -- the new "engine snapshot" method (which does not store files to disk because they would be way too huge) allows for instant reloading of the game state to the point of the last time saving the tape, which hopefully helps in over 90% of typical situations where you need such a speedup (without cluttering your hard disk with lots of files that are several megabytes in size).
Is there *really* a need for more CEs? (Yes, Alan, I know your opinion about this -- you would ask for more CEs even if there were 1024 of them ;-) ;-) )
But it just occurred to me that it may not be better to add too many more CEs, or nobody will ever finish a level because they could always make it better!
:
