RSS | Page 1 2 Moving platforms
Update time!
I've spent the past few months improving existing code, so there wasn't much to write about.
Everytime I do a change in the source ten more things pop up that scream to be added. It's scary! How could NES developers back in the 80s cope with tight deadlines?
Anyway, the last thing I did was a complete rewrite of the background tile collision code. While I was at it I decided to add support for moving platforms.
Man, that was a shitty idea. Pandora's can of worms (or what they call it) was opened!
There's a thread on the nesdev BBS that I shamelessly used to do a brain dump on this topic.
I also wrote some C code to prototype background collision and moving platforms:
Source code
Windows binary
Just wanted to share. It was designed with the NES's processing power in mind and it may not be the best way of doing it, but if any fellow developer can benefit from the ideas presented then my job is done.
Comments (2)
Bi-directional scrolling
Okay, so I had finally set up all my code to run on a UNROM board, but then it occured to me that with all the RPG elements and not-too-linear gameplay I'm aiming at, saving the player's progress is going to be a huge problem.
Should I use a password system? Sounds cool, eh? It is, if you love typing a bazillion pages of random letters and numbers with your controller every time you want to play. Because that's what a game like Zelda would have been like if it used a password system (anyone remember Golden Sun's item and character transfer codes?).
Luckily, the guys at Nintendo were CLEVER, so they came up with the idea of putting a RAM chip on the board. They also connected a battery to it, which, by two decades or so, increased the time span said RAM would keep its data after the console had been turned off.
Yeah, you all know that. So, long story short, I switched mappers once again. This time to MMC1, which allows for battery-backed SRAM.
Save game support is nice, but the real fun is having an additional 8K of RAM.
It enabled me to have an uncompressed map accessible in memory at all times, which I implemented without any hassle one week ago.
What I've been working on since is free bi-directional scrolling (like e.g. in Super Mario Bros. 3). Not a big deal, you think? Read this and this and think again!
I'm using Vertical Mirroring. Hebereke/Ufouria is one of the few commercial games I'm aware of that uses the same setup for bi-directional scrolling, but it does a horrible job at it. Ugly scrolling artifacts on the right and bottom of the screen? We definitely don't want that!
This is how my game currently handles scrolling: Behold the beauty of animated GIFs. (2:1 scale)
If a new row or column of tiles needs to be drawn the engine first buffers it into ram. The bottom portion of the stack, starting at $0100, is a good place to keep such data since, unless you write weird recursive functions, chances are it will remain unused.
We can only update graphics in vblank. But vblank only lasts for about 20 scanlines (or 2270 CPU cycles) on NTSC consoles, so it's a good idea to experiment with different methods of pre-buffering data to make copying it to VRAM as fast as possible when the time has come.
With the ridiculous amount of RAM I now reign over I thought it would be cool to try something new: Generating the entire graphics update code in RAM, then just executing it during vblank.
I also tried spreading the update of one row of 16x16 tiles over two frames, drawing one row of 8x8 tiles each frame. Takes about 230 cycles per vblank while the (still highly unoptimized) code that prepares scrolling outside of vblank currently peaks at 3700 cycles.
As you can see, the scrolling on NTSC TVs with overscan looks all clean and spiffy. On the average PAL TV, however, you will be able to see artifacts at the top and bottom while scrolling vertically. There may possibly be ways to get rid of them, but for now I'll just say: "Screw you, PAL people!" (yes, that includes myself)
Now, I didn't even tell you about attribute updates and all the complications of updating data across multiple nametables. This is where the real fun begins and the part my engine doesn't yet handle flawlessly. I'm not even gonna try to explain all this.
With MMC1 I could have gone for Single-screen Mirroring which would simplify things a lot, but I wanted a method that works on other mappers as well. After all, there could be a mapper switch again if for some reason I change my mind about battery-backed saves in the future.
Anyway, I've been putting a lot of work into both graphics and code over the last couple of weeks. It's coming along nicely. Hope I'll have a new rom to show next time.
Comments (8)
Map editor
TileStudio is fun, but slow as hell when working with large maps. Hence, I decided to start a new map editor from scratch. I didn't go through the hassle of writing a GUI-based application this time, but instead used Allegro and made all functions accessible through keyboard shortcuts.
The results after one and a half weeks of coding: a terribly messy piece of code which actually compiles into a usable map editor with an even better workflow than both TileStudio and my old editor.
Also, it has a few cool features that I've always wanted:
- screen editor - change tileset and palette numbers of each screen
- tileset editor that provides immediate visual feedback
- preview mode - renders the map using Blargg's NTSC Library
- real-time graphics editing - the editor automatically reloads the graphics and palette files if they have been altered by an external program such as YY-CHR
I've uploaded a video again that shows off all this:
http://www.youtube.com/watch?v=DjYeB604a1s
Comments (5)
Not dead
Not at all!
I might not be able to spend a lot of time on the platformer within the next few weeks. An update has been long overdue, so yeah...
Here is a list of what's new:
- slope tiles (partially implemented)
- dialog boxes
- NPCs and scripted events (for triggering dialog boxes, setting game variables, etc.)
- water physics and "effects" (using the particle engine)
- new, but still far from perfect graphics and sound effects!
Enough of the talk, my brain refuses to phrase anything remotely comprehensible today. :) Instead, I have uploaded a video to Youtube that should speak for itself.
Comments (6)
Particle systems
Look at these screenshots taken from popular NES titles:
Imagine the fun Trevor Belmont's mum will have doing the laundry. Play with the giant toads in the swamp and you risk some nasty mud stains!
Furthermore, the explosion, air bubbles or the trail of tiny stars... These are all details that, while playing, you will soon start to forget about and only perceive subconsciously. And that's the trick. They breathe life into the game by depicting features and physics of the real world.
Actually, still images don't do these scenes justice, I recommend you to dust off your NES to play and watch the games yourself.
There are certainly more important points on my to-do list right now, but I needed a diversion. So I came up with my own particle engine:
Download particle.nes
Download source code
In my platformer engine it will make sense to separate particles from normal sprites. Particles won't need many of the features that sprites offer (such as collision detection), therefore they will naturally perform better with custom code.
Comments (3)
Subscribe to RSS feed