On 9/5/07, James Paige <[EMAIL PROTECTED]> wrote: > On Wed, Sep 05, 2007 at 04:01:54AM +1200, Ralph Versteegen wrote: > > I've been thinking up Voxhumana features for years! > > I realise there are a lot small user requests on bugzilla. Most of > > them seem to be battle system requests. But there are also very large > > things I hear over and over again like running multiple scripts at > > once, a new map editor, not having to split animations up into NPC > > walkabouts, etc, which are normally the ones that need more planning. > > Here are *some* of the things (in outline) I'd like to get in (not all > > of these are possible to complete to totality within a reasonable > > release time, but I don't think any of them are hard, unlike sound > > effects and music, which was very hard) > > As long as everything is done in small careful well-planned > well-tested steps to avoid breakage, the sky is the limit! > > > -New saved game format > > *Required for lots of features, like more global varaibles, arrays, > > permanent map state saving > > *James previously said we should start on this first thing after > > Ubersetzung branches. Yes, but I think even more pressing is... > > Something that worries me a lot about this one is save-game > incompatabilities. Suppose you release a 50% demo of your game, which > uses permanent map state saving. Everybody plays it, loves it, and > eagerly awaits the full release-- but when you release it, it is > horribly broken for everybody who has a saved-game from the 50% version. > > We already have some smallish breakages from that type of problem > already, but with map state saving added to the mix, I anticipate it > getting *much* worse. We need to think about how to resolve save game > versioning problems. > > > -Graphics rewrite! > > *Required for a very broad range of large feature request > > *I think the OHR runs very slowly, I can't crank zoom up much on my > > computer > > *We need a new graphical function set which uses backend blitting > > functions, to allow hardware acceleration and the like > > *A sprite UDT. It's internals could be graphical backend dependent > > *Maintain backwards compatibility with the old modex functions so we > > can convert everything slowly > > *A set of script commands for displaying sprites on map. > > Creating sprites on the maps is something I have fantasized about in the > back of my head for quite some time. I want to be able to "pin" these > sprites to either the screen or the map or an NPC, and then have > commands for adjusting their x/y relative to whatever they are pinned > to. > > I think this type of pinning would be nice to add to strings also, and I > would like it for the rectangle interface I have been mumbling about on > the wiki (map sprites an the rect interface actually have a ton in > common)
Ah yes, strings and sprites should be pinnable to 4 types of things: absolute screen positions, map positions, npcs, and heroes. > > Of course, James suggested even more radical features like storing all > > sprites as 32-bit pngs. That wouldn't be too difficult after the above > > (no idea when it might happen) > > We will want to make some sprite storage changes. How exactly will be a > topic for discussion. > > > It would be really great if we could allow more than 160 tiles on a > > maptile set (maybe we could allow multiples of 160?), > > Yes, that one should actually not be to hard. And 16/32/something bits per tile would almost require we look at upgrading tile animations too. > > > and optionally > > running at more than 320x200 where it's convenient (prehaps 320x400 or > > 640x400, times zoom, for the new map editor). This prospect is only > > scary if you consider the OHR a QBASIC-heavily-beefed-up-with-FBisms > > project. > > This is a can of worms I am not ready to open yet. Maybe you're right, but it's time to make some improvements to the map editor, and theres such a host of possible future improvements that it might be time to do a really thorough flexmenu style cleanup/rewrite. You never know where we might get. Unless you mean can-of-worms in the "users will demand higher resolution in Game!" way, which worries me greatly. > > > -Allow separate maptile sets for each layer > > > > -Many script (interpreter) upgrades. This includes: > > *Subifying the interpreter and the script commands in game (module > > level shared variables) > > *Implementing "threads" > > ~I feel this is planned out well enough to start, but I might not have > > time > > ~The debugger will need another upgrade too > > *Attempt a huge speedup, through: > > ~Bring the interpreter closer to its stack (macros instead of > > allmodex functions) -sideeffect of threads, actually > > ~Remove GOSUBs, or find a faster assembly GOSUB workaround > > ~Evaluate constants and variables without increasing depth (pushing > > interpreter state to the stack) > > ~Look into ways of improving the interpreter loop > > ~Possibly pushing less onto the stack? Loop stack use? > > The whole threading thing opens up a lot of possibilities. My main > concern is how to keep it backcompat with old games. Simply: require a bitset to enable them. This bitset is off by default for existing games, on for newly created ones. Maybe we can also have a 3rd mode, when triggered scripts block each other, but scripts can create new threads. For people who want to take an old game (or their old way of thinking) and add concurrent scripts at some point without having to rethink the whole game. > > > *Arrays! We never decided on the details, but I really would like > > them this time: I've been delaying OHR games for them! > > These shouldn't be to hard. I think we can definitely get them in. Except I feel like doing them as . Strings were slightly hacking in implementation, I think, not really well integrated with the rest of the language. > > > -Also, I'd like to do a bit of work on gfx_sdl, because I prefer SDL > > to FB's libraries > > I agree. SDL is dog slow now, but that can be fixed, and once it is > ready, I think all our fullscreen-related bugs will vanish into the > mist. > > --- > James Paige _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
