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~
For some bizarre reason of which I will not question, I've never been this wired in my life before. I had a standard lunch and coffee- no different than before. I've gotten lots of work and errands done today already and it has just begun. Yay ^^
Well, I might as well take advantage of the situation. With this time, I'm going to go rushing through this as fast as I can go to maximum fatigue which is something I haven't done since last Christmas. Expect there to be a ton of stuff done on the engine by tonight and I'll give my report~
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.
The instruction booklet included with the engine explains the features different or added to by my engine. However, I think some of you are both a little shaky on RPG Maker 2003 and the idea of 20XX. When there's complete feature families, I think it might be good to submit an actual tutorial and link it here for doing something particular step-by-step.
These tutorials would teach you simultaneously how to use RPG Maker 2003 and 20XX together as though you knew little of both. They would explain how to use a handful of features altogether instead of each one by itself.
It's coming, I'm not far away from this stage just yet.
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.
Alright, I fixed the event <-> hero collision trigger so that it actually works. Turns out I never really did implement it in the first place and I don't know why. It's the classic on-screen enemy encounter catalyst! I've also added more to move event commands, which includes the change graphic move command.
Here's a dump of the rest of what I've done since last time:
- Added support for multiple RTP folders and RPG Maker 2000 standard folder
- Fixed: reporting an event with no name crashes the engine
- Added conditional branches and while loops
- Added calling of common events
- Added calling of pages out of other map events
- Added common events that are parallel/auto on switches or not
- Fixed: Touch/Collision didn't do anything for event triggers
- Fixed: Events weren't transparent if that box was checked
- Added some more move commands like move to hero, change graphic, etc.
Now for the release date. I'm going to try hitting March 20th for the beta. It might still be unfinished, but it should be possible to play and make games with. Hopefully I can integrate the rest of the database as easily as before.
Links are up there, the download now also has the instruction manual in it.
The instruction manual is incomplete as it's missing lots of the extras you'd find in a manual, and it only documents things that actually work completely in the engine.
The menu doesn't do anything yet, and there's no battles yet. Supported commands are listed in the tabs up there, so check them before filing a bug report because you used a command that was not yet implemented.