3.2.0rc1
Moderators: Flumminator, Zomis
-
Flumminator
- Posts: 184
- Joined: Fri Jun 18, 2004 8:08 pm
- Location: Germany
-
RTA K545
> I truly agree with bojster, use 3.1.0 instead. It's much more stable.
Although I know what you mean and agree: If you find 3.2.0-rcX really being "unstable" in sense of crashing or something like that, please report it as a bug. (There is one known crashing bug when using certain MOD tunes which is not tracked down yet.)
> > I shall wait until the next official release.
> ...which will hopefully come out soon enough.
The final 3.2.0 might still need more time than expected, and it is currently possible that there will be a bug-fix-only version 3.1.1 before. This is to prevent people from creating lots of levels and tapes that won't work with 3.2.0 due to bugs (also I will add a lot of compatibility code to 3.2.0 to handle this as best as possible).
Although I know what you mean and agree: If you find 3.2.0-rcX really being "unstable" in sense of crashing or something like that, please report it as a bug. (There is one known crashing bug when using certain MOD tunes which is not tracked down yet.)
> > I shall wait until the next official release.
> ...which will hopefully come out soon enough.
The final 3.2.0 might still need more time than expected, and it is currently possible that there will be a bug-fix-only version 3.1.1 before. This is to prevent people from creating lots of levels and tapes that won't work with 3.2.0 due to bugs (also I will add a lot of compatibility code to 3.2.0 to handle this as best as possible).
Well, actually I haven't tested it that much. But I've seen reports in the pre-3.2.0-1 threadHolger wrote:> I truly agree with bojster, use 3.1.0 instead. It's much more stable.
Although I know what you mean and agree: If you find 3.2.0-rcX really being "unstable" in sense of crashing or something like that, please report it as a bug. (There is one known crashing bug when using certain MOD tunes which is not tracked down yet.)
Hm... would it be possible (maybe as an option during building/installing?) to create a separate tool to convert the tapes? I wouldn't like RnD to be bloated, with all these levelsets and pre-loading everything on startup it works a bit slow already... (I guess I've already mentioned this issue elsewhere, also with connection to the fact that RnD won't start w/o music files though I don't use the sound anyway).Holger wrote:(also I will add a lot of compatibility code to 3.2.0 to handle this as best as possible).
> Hm... would it be possible (maybe as an option during building/installing?) to
> create a separate tool to convert the tapes?
Unfortunately not. Even very little changes to the game engine can break tapes so effectively, that it is completely impossible to "convert" old tapes to solve levels using a changed game engine. The only two solutions are providing compatibility code to play old tapes with old engine code, or to completely re-record the affected tapes. That's what it makes that difficult...
> I wouldn't like RnD to be bloated,
> with all these levelsets and pre-loading everything on startup it works a bit
> slow already... (I guess I've already mentioned this issue elsewhere, also
> with connection to the fact that RnD won't start w/o music files though I don't
> use the sound anyway).
Yes, this is bad and should be changed. Loading the needed sounds and music if the player later switches on sound and/or music shouldn't be too hard...
> create a separate tool to convert the tapes?
Unfortunately not. Even very little changes to the game engine can break tapes so effectively, that it is completely impossible to "convert" old tapes to solve levels using a changed game engine. The only two solutions are providing compatibility code to play old tapes with old engine code, or to completely re-record the affected tapes. That's what it makes that difficult...
> I wouldn't like RnD to be bloated,
> with all these levelsets and pre-loading everything on startup it works a bit
> slow already... (I guess I've already mentioned this issue elsewhere, also
> with connection to the fact that RnD won't start w/o music files though I don't
> use the sound anyway).
Yes, this is bad and should be changed. Loading the needed sounds and music if the player later switches on sound and/or music shouldn't be too hard...
-
RTA K545
I think each levelset (plus any sounds/graphics) should be loaded when you go to play it, instead of when you load the program. That way, the game would load much faster. This is also good, because it is very unlikely that you are going to play every levelset every time you play RnD.bojster wrote:I wouldn't like RnD to be bloated, with all these levelsets and pre-loading everything on startup it works a bit slow already...
> I think each levelset (plus any sounds/graphics) should be loaded when you
> go to play it, instead of when you load the program. That way, the game
> would load much faster. This is also good, because it is very unlikely that you
> are going to play every levelset every time you play RnD.
I think there is a misunderstanding about what R'n'D does at startup. Besides the sound/music issue (which I should fix), R'n'D only ever loads the directory structure of your level directory at startup, but it does *not* load all the artwork for these sets! Of course it loads the artwork for the *current* set, but whenever you switch level sets, it unloads the old artwork and loads the new one (in fact, it currently "overwrites" the artwork internally, which also causes a bug already reported which can lead to some old artwork still visible). So if the game loads too slow an your system, it's probably because of a high number of level sets in your level directory. (R'n'D has to look for *all* sets recursively, because a network game might request a certain set by name, so it's not enough to look for them on the level selection screen for each entered sub-directory.)
> go to play it, instead of when you load the program. That way, the game
> would load much faster. This is also good, because it is very unlikely that you
> are going to play every levelset every time you play RnD.
I think there is a misunderstanding about what R'n'D does at startup. Besides the sound/music issue (which I should fix), R'n'D only ever loads the directory structure of your level directory at startup, but it does *not* load all the artwork for these sets! Of course it loads the artwork for the *current* set, but whenever you switch level sets, it unloads the old artwork and loads the new one (in fact, it currently "overwrites" the artwork internally, which also causes a bug already reported which can lead to some old artwork still visible). So if the game loads too slow an your system, it's probably because of a high number of level sets in your level directory. (R'n'D has to look for *all* sets recursively, because a network game might request a certain set by name, so it's not enough to look for them on the level selection screen for each entered sub-directory.)
Ah, that's a relief... :-)
Maybe it would be possible to, sort of, cache the information RnD seeks/load at startup? It would greatly increase the startup speed and would only require updating the cache when new levelsets are added (any info that changes when RnD is running could be automatically updated in the cache), e.g. with a special menu option or some such... If it's possible, just put it somewhere in the end of the TODO list... ;-)
Maybe it would be possible to, sort of, cache the information RnD seeks/load at startup? It would greatly increase the startup speed and would only require updating the cache when new levelsets are added (any info that changes when RnD is running could be automatically updated in the cache), e.g. with a special menu option or some such... If it's possible, just put it somewhere in the end of the TODO list... ;-)
Caching would be possible, probably... (Although I'm sure that nobody beside you and me would find and use such a "update level cache now" button, so it would be needed to do this automatically.)
Another bottle-neck at startup is that currently all artwork config files are completely parsed, to be able to show the artwork name in the artwork selection menu. As artwork config files tend to grow quite big, this slows down starting the game when having a lot of custom artwork level sets. (Although it is still usable -- on my old PC -- even with the not-yet-released hundreds of new EMC level sets, each with a large artwork config file.) A solution for slower systems would be to stop parsing when reaching the "name: xxx" entry (which usually is at the start) and fully reading them only when the set was selected.
Another bottle-neck at startup is that currently all artwork config files are completely parsed, to be able to show the artwork name in the artwork selection menu. As artwork config files tend to grow quite big, this slows down starting the game when having a lot of custom artwork level sets. (Although it is still usable -- on my old PC -- even with the not-yet-released hundreds of new EMC level sets, each with a large artwork config file.) A solution for slower systems would be to stop parsing when reaching the "name: xxx" entry (which usually is at the start) and fully reading them only when the set was selected.