wraggster
August 15th, 2008, 23:24
Eponasoft posted this news on the development of the RPG Maker DS:
The overlay layer covers everything. The object layer overlays the base layer but not the sprites, since the sprites reside on the object layer. The interface *never touches this screen*. The UI exists only on the touchscreen, never on the top screen. When dialogue is displayed, it will temporarily overwrite tiles on the overlay layer, and then will be rebuilt when the dialogue is finished. However, I am considering doing away with the parallax layer and simply using the topmost layer exclusively for dialogue to avoid this.
The sprites will be 4 or 8 bit (user choice), and in the builder, you will be able to manually affect the color pools. Every sprite you add to the scene must work within the 16 palettes (15 actually, since the "hero" sprite gets its own dedicated palette). I considered dynamic allocation of palettes at runtime but this could easily turn into a mess so I decided against it (imagine 30 sprites vying for unique palettes).
As for tile size, 16x16 is for the map editor only. The builder will convert the 16x16 tile blocks to the 8x8 standard that the DS uses. It will also perform tile redundancy optimization on the resulting 8x8 tiles.
RPG Makers on the PC have very specialized rules for handling the various layers of tiles, as well as the tiles themselves. These rules will not be replicated here, not only for simplicity's sake but also for efficiency's sake.
As for the book example...that's no problem. The same book can be used for both locations, unless you plan on having your character jumping on the bed, standing on the table, etc. Just place it on the overlay layer. It simply requires smart tile placement. The apple on the tree example is a good one though...the only way around that would be to have TWO overlay layers, but I think that's a bit of overkill. However, 128 tiles is not a bad thing. There are plenty of games that don't use tons of tiles, and they look great. Of course, the actual limit will be lower because you also need to store the sprites in VRAM.
For sound...MP3 is the best option we have available right now. mikmod is pretty universally known as "crap", though right now it's the only module solution there is. It just generally consumes a hell of a lot more memory than the MP3 player does, since the MP3 player streams from the filesystem and doesn't load the whole thing into memory. MIDI though? MIDI is impractical for the DS, especially General MIDI. You have to have sound banks for it similar to how modules work, plus the additional overhead of managing multiple channels dynamically. It's a real nightmare sometimes, and I sure wouldn't want to write such a frankenstein of a player.
Again, I thank you for your insight, it's good to know there's some hardware-knowledgeable people on the forum. PAlib lets you ignore the limits sometimes so not everyone gets to learn the "on the metal" details of how the system works.
http://forum.palib.info/index.php?topic=5400.30
The overlay layer covers everything. The object layer overlays the base layer but not the sprites, since the sprites reside on the object layer. The interface *never touches this screen*. The UI exists only on the touchscreen, never on the top screen. When dialogue is displayed, it will temporarily overwrite tiles on the overlay layer, and then will be rebuilt when the dialogue is finished. However, I am considering doing away with the parallax layer and simply using the topmost layer exclusively for dialogue to avoid this.
The sprites will be 4 or 8 bit (user choice), and in the builder, you will be able to manually affect the color pools. Every sprite you add to the scene must work within the 16 palettes (15 actually, since the "hero" sprite gets its own dedicated palette). I considered dynamic allocation of palettes at runtime but this could easily turn into a mess so I decided against it (imagine 30 sprites vying for unique palettes).
As for tile size, 16x16 is for the map editor only. The builder will convert the 16x16 tile blocks to the 8x8 standard that the DS uses. It will also perform tile redundancy optimization on the resulting 8x8 tiles.
RPG Makers on the PC have very specialized rules for handling the various layers of tiles, as well as the tiles themselves. These rules will not be replicated here, not only for simplicity's sake but also for efficiency's sake.
As for the book example...that's no problem. The same book can be used for both locations, unless you plan on having your character jumping on the bed, standing on the table, etc. Just place it on the overlay layer. It simply requires smart tile placement. The apple on the tree example is a good one though...the only way around that would be to have TWO overlay layers, but I think that's a bit of overkill. However, 128 tiles is not a bad thing. There are plenty of games that don't use tons of tiles, and they look great. Of course, the actual limit will be lower because you also need to store the sprites in VRAM.
For sound...MP3 is the best option we have available right now. mikmod is pretty universally known as "crap", though right now it's the only module solution there is. It just generally consumes a hell of a lot more memory than the MP3 player does, since the MP3 player streams from the filesystem and doesn't load the whole thing into memory. MIDI though? MIDI is impractical for the DS, especially General MIDI. You have to have sound banks for it similar to how modules work, plus the additional overhead of managing multiple channels dynamically. It's a real nightmare sometimes, and I sure wouldn't want to write such a frankenstein of a player.
Again, I thank you for your insight, it's good to know there's some hardware-knowledgeable people on the forum. PAlib lets you ignore the limits sometimes so not everyone gets to learn the "on the metal" details of how the system works.
http://forum.palib.info/index.php?topic=5400.30