RPG Maker 20XX Engine

I'm finally done with the visually nasty stuff in terms of DirectX and RPG Maker 2003. Because of the way I implemented framebuffer effects to do screen tones, I can apply an HLSL shader to the texture.

Currently, a software fallback is implemented for both pictures and the screen. It runs alright unless you use the saturation slider, then it starts to slow a little on this netbook. I could implement much cooler effects, but this would be horribly slow on many computers if I did it in software. For more advanced effects, I'll have some HLSL effects.

I can arbitrarily modify the screen at any time to apply a screen effect. All together now, this creates some interesting effects.

Let's say you have a mirror plane, this is how the drawing will look:

1. Draw lower tiles below the mirror plane (draw any lower tile set as a mirror plane)
2. Apply screen effect using a water shader
3. Draw the mirrored sprite pictures
4. Draw normal lower tiles (upper/lower)
5. Draw sprites
6. Draw upper tiles and sprites that are to appear above things
7. Apply a screen effect if using screen tint / or apply an HDR effect

So you'll get the typical "Next-Gen" treatment on this 2D game. If an effect is supposed to be applied to a specific object, it gets used right when that object is drawn and gets attached to that object instead of being explicitly used in the drawing loop.

Terms
Framebuffer - The best examples of Framebuffer Effects were the swirls and effects when you entered a battle in Final Fantasy games on the PS1.
HLSL - This is an entire programming language designed for special effects on video cards. Chrome, Normal Mapping, Water Effects, Bloom, HDR, etc. (pretty much any effects you see now these days) were written as "Shaders" in these languages.
software fallback - "Fallbacks" are things you do when some features aren't present on a computer. If your computer does not have shader model 2.0, it will use these techniques I wrote today. If it does, the shader will run much faster than my software fallback.

There's actually a character in Aquatallion called Mr. Save who you talk to in order to... save.

Anyway, you can pretty much... save. It works, and it works well even when I keep changing the sizes of entries in the database and adding new save data to the format. And it all gets saved into your home folder so it doesn't matter where you put each game itself.

Here's the full list of stuff I did:
- Added title skipping
- Added default moving patterns on pages
- Fixed a square (passable at top) tileset collision bug in one tile
- Added folders for game saves
- Fixed the DirectX device lost problem
- Added save loading menu
- Added saving and loading of game files
- Added saving and loading of variables/switches
- Added saving and loading of the party
- Added allow/disallow saving
- Added open save menu and open main menu for event commands

Oh yeah, and you're going to fucking love the new menu system.

I'll go get the rest of the menu working and that will be one third of the entire project. When I get more stuff working in the database linked to the menu, I can also get it working in event commands. See you soon~

I finally implemented the part of the engine that re-acquires the DirectX device when lost so that the application keeps working even if you ALT+Tab the game. It took some figuring out, but I got it down on the first try! It doesn't usually work that well.

I've currently been working on the save menus so that games can be saved. The old .LSD format is being dropped for my own format. I've been designing this new format to resist increasing and decreasing database entries so it should survive project upgrades/downgrades when using old saves. One of the only problems that will occur will be game saves saved on a map that no longer exists. Having a hero or item in your party that no longer exists would cause a problem too.

Just avoid reducing the database, which is a good practice regardless of what engine you decide to use. Blank out the entries with the DELETE key and enter dashes or something so you can tell what objects shouldn't be there.


The sample game I've been making is already loaded into the RMN game page queue and awaiting someone to approve it, so it should appear sometime later.

I'm going to see how I can get this engine to start from the editor with all the options intact. There are four modes of play available in the original RPG_RT.exe:

- Play Test mode where you can access the variables and switches, and there's a way to interrupt and shut down the game.
- Battle Test mode where the engine takes player settings and plays a battle only.
- A method of starting in window or fullscreen mode
- A method of hiding the title screen (why!? you still have to select new game)

If I can get the engine to work with these modes, then it will work better with the editor and you don't have to keep clicking on wcrpg2kxe.exe

The new menu system will be completely redone. Right now, I'm implementing the inventory system. This will implement item management commands, and even allow you to use items whose function is turning on switches. The items will be listed in a single list (not a table of 2 columns and N rows) and sorted in alphabetical order. Pressing left and right instead lets you select a tab that filters items by type. I love defining items in design order in the database, but this messes up any sorting you could be going for. This way, you can quickly find the item you want for those games with lots of different items.

I've implemented the branching, while, and other program control commands. Now the system is suddenly much more playable now that it actually does logical processing and the like.

Now, I think the next thing to implement would be the Common Event calls and input.