Goplanes
Moderator: Mask of Destiny
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
This past week I've been working on getting gensKMod running in Visual Studio 2010 and making little tweaks to its window behaviour.
Things like:
- Fixing a bug where the emulator wouldn't wouldn't be in focus when started
- Saving and restoring the visibility and position of the debug message
window
- Adding a hot key to toggle the debug message window.
And I'll probably add more like these in the future.
I've noticed that gensKMod is pretty old, so before I start doing any more serious work to it, I'd like to ask: Are there any other emulators that are considered better from a programming/debugging standpoint? At the moment, the killer feature is the debug message window. It's incredibly handy to do a KDebug_Alert() in genesis code and have it show up in the debug message window. I've checked out a few other versions of Gens (original and Gens GS. Gens KMod++ simply doesn't work in my setup) and they don't have it.
So, what else is out there?
Thanks!
DJCC
Things like:
- Fixing a bug where the emulator wouldn't wouldn't be in focus when started
- Saving and restoring the visibility and position of the debug message
window
- Adding a hot key to toggle the debug message window.
And I'll probably add more like these in the future.
I've noticed that gensKMod is pretty old, so before I start doing any more serious work to it, I'd like to ask: Are there any other emulators that are considered better from a programming/debugging standpoint? At the moment, the killer feature is the debug message window. It's incredibly handy to do a KDebug_Alert() in genesis code and have it show up in the debug message window. I've checked out a few other versions of Gens (original and Gens GS. Gens KMod++ simply doesn't work in my setup) and they don't have it.
So, what else is out there?
Thanks!
DJCC
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Two weeks since my last Goplanes update doesn't mean I haven't been busy
http://youtu.be/X5qicQVCXM8
From the description:
What may be simple firing of bullets is actually two weeks of refactoring and building new systems, like the beginnings of a game object lifecycle/scenegraph/visibility management system thing. So while there isn't a lot of new visible features in the game, the code base has been changed for it to be more expandable and more sensibly laid out. It will be simpler to add new types of objects, like explosion effects and enemies.
I'm certain the object management system will be one system that I'll be rewriting from scratch over and over again, trying to keep it efficient but flexible for the game's needs.
One puzzle I'm trying to figure out is the mystery of the flickering/disappearing bullets. I've only really got 7 sprites on screen and since the genesis can handle a total of 80 with 10 per line I'm not sure what's going on. Maybe old invisible sprites are screwing things up. Or, my object management code is buggy. Shocker.
http://youtu.be/X5qicQVCXM8
From the description:
What may be simple firing of bullets is actually two weeks of refactoring and building new systems, like the beginnings of a game object lifecycle/scenegraph/visibility management system thing. So while there isn't a lot of new visible features in the game, the code base has been changed for it to be more expandable and more sensibly laid out. It will be simpler to add new types of objects, like explosion effects and enemies.
I'm certain the object management system will be one system that I'll be rewriting from scratch over and over again, trying to keep it efficient but flexible for the game's needs.
One puzzle I'm trying to figure out is the mystery of the flickering/disappearing bullets. I've only really got 7 sprites on screen and since the genesis can handle a total of 80 with 10 per line I'm not sure what's going on. Maybe old invisible sprites are screwing things up. Or, my object management code is buggy. Shocker.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Oh yes, that's right. I was just saying I didn't understand why they were disappearing because there were so few sprites on screenShiru wrote:Genesis can handle 20 sprites per line, actually.
Yes, that was exactly it.Shiru wrote:Perhaps links in your sprite list are broken at some point, and that's make some part of it disappear.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
http://youtu.be/tO7LMUyExqs
The last video was boring, so I added an explosion sprite and changed the bullet firing to make it look more exciting.
The last video was boring, so I added an explosion sprite and changed the bullet firing to make it look more exciting.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
This is looking more and more fun every time
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Latest update:
http://youtu.be/jurSxdhL1fA
From the description:
I've added a few little effects, like a muzzle flash and a poof when the Goplane hits the wall. Refactored the drawing code to be object-specific and more flexible. While the plane is a normal 24x24 sprite (used to be 32x32 until I noticed it had way too much empty space) the poof is actually four 8x8 sprites of the same image, but mirrored for each corner. I have a feeling that's how I'll be making a lot of sprites to save memory.
What really bugs me is the weird sprite glitching around the plane when I'm flying around in circles and firing bullets. I have no idea what's causing this. I've tried moving around the sprite rendering to be sooner in the frame, but no luck. This video is running off an emulator, but it shows up on hardware as well.
-----
The glitches on hardware are very similar but appear worse. I've added screen shots of the glitches running in Gens. It's not 100% representative, as the emulator and the video capture might be causing some of it, but it looks very similar. Long glitchy white/yellow lines above, below and across the plane.
Screenshots: http://imgur.com/a/sNUMq
http://youtu.be/jurSxdhL1fA
From the description:
I've added a few little effects, like a muzzle flash and a poof when the Goplane hits the wall. Refactored the drawing code to be object-specific and more flexible. While the plane is a normal 24x24 sprite (used to be 32x32 until I noticed it had way too much empty space) the poof is actually four 8x8 sprites of the same image, but mirrored for each corner. I have a feeling that's how I'll be making a lot of sprites to save memory.
What really bugs me is the weird sprite glitching around the plane when I'm flying around in circles and firing bullets. I have no idea what's causing this. I've tried moving around the sprite rendering to be sooner in the frame, but no luck. This video is running off an emulator, but it shows up on hardware as well.
-----
The glitches on hardware are very similar but appear worse. I've added screen shots of the glitches running in Gens. It's not 100% representative, as the emulator and the video capture might be causing some of it, but it looks very similar. Long glitchy white/yellow lines above, below and across the plane.
Screenshots: http://imgur.com/a/sNUMq
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
sikthehedgehog on Youtube pointed out that I was probably updating my sprite table too late after vsync, and sure enough that was the problem. I figured it was something like that.
I was waiting for vsync, then drawing sprites through SGDK's functions but only calling its VDP_updateSprites function at the very end after updating the game logic. So that was bad. It's now called right after the sprites are set and the glitches are gone. Phew!
I was waiting for vsync, then drawing sprites through SGDK's functions but only calling its VDP_updateSprites function at the very end after updating the game logic. So that was bad. It's now called right after the sprites are set and the glitches are gone. Phew!
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
http://www.youtube.com/watch?v=prqrxj7wA3Q
Added the beginnings of gameplay elements and the structure to add them.
There are now basic enemies that fire enemy projectiles and have death sequences with effects. The player's plane also now has a death sequence.
Added a large explosion sprite, because large explosion sprites are awesome.
The player and enemies have health points and bullets can cause damage. The player gets three hits before getting destroyed. Enemies have one health point. Bullets on either side do one point of damage. The player flashes after getting hit, but it's hard to tell on the video. It's also hard to tell while playing. Will have to come up with a better idea.
Slowed down the plane a little bit as targeting enemies and avoiding enemy bullets was pretty hard. Levels will have to be bigger to make it easier on the player to navigate and dogfight.
Also, obviously, added collisions between player bullets and enemies, and between the enemy bullets and the player. Collisions are box-box. But it's far from perfect as bullets sometimes fly through enemies as you can see. Also, I'm experiencing random crashes which I haven't been able to pin down, but I suspect is with the collision code. On the emulator, I get "Illegal instruction!" while on hardware I get "address error!". Maybe a bad function pointer.
At the end of the video, I manually kill the player object with a button press. I'm probably generating an excessive amount of explosions during the player's death sequence and will have to tone it down. It's still cool, though.
Added the beginnings of gameplay elements and the structure to add them.
There are now basic enemies that fire enemy projectiles and have death sequences with effects. The player's plane also now has a death sequence.
Added a large explosion sprite, because large explosion sprites are awesome.
The player and enemies have health points and bullets can cause damage. The player gets three hits before getting destroyed. Enemies have one health point. Bullets on either side do one point of damage. The player flashes after getting hit, but it's hard to tell on the video. It's also hard to tell while playing. Will have to come up with a better idea.
Slowed down the plane a little bit as targeting enemies and avoiding enemy bullets was pretty hard. Levels will have to be bigger to make it easier on the player to navigate and dogfight.
Also, obviously, added collisions between player bullets and enemies, and between the enemy bullets and the player. Collisions are box-box. But it's far from perfect as bullets sometimes fly through enemies as you can see. Also, I'm experiencing random crashes which I haven't been able to pin down, but I suspect is with the collision code. On the emulator, I get "Illegal instruction!" while on hardware I get "address error!". Maybe a bad function pointer.
At the end of the video, I manually kill the player object with a button press. I'm probably generating an excessive amount of explosions during the player's death sequence and will have to tone it down. It's still cool, though.
-
- Very interested
- Posts: 145
- Joined: Sun Jan 28, 2007 2:01 am
- Location: DCEvolution.net
- Contact:
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
http://www.youtube.com/watch?v=Cv9s1H32RSc
Goplanes Dev Video 012:
Added the beginnings of a in-game hud and coin pick up items.
I wanted to add coins so that the player can have a reward for exploring a map. Also, since maps will be pretty large, it'll help the player navigate around, since coins can also lead the player to interesting spots and goals. Similar to how coins are used in the Super Mario Bros. games.
Coins are sprite based and tile based. Sprite-based coins are of a new kind of object called "pickups". That'll be used for power ups and similar items later.
Tile-based coins were a challenge. I had to come up with a solution to change the appearance of the tile map without 1) copying the large tile map to ram and 2) keeping memory usage as low as possible but 3) still have a lot of coins in a map.
Since every tile in rom was using 16 bits and I'm only really going to use 8 bits of them anyway (for a max of 256 tiles per background plane) , I've decided to use the upper 8 bits as tile type-specific data. Depending on the type of tile (non-solid, solid, coin), the upper 8 bits can be used for extra information. In the case of a coin-type tile, the upper 8 bits is an index into a array of coin states. Every coin in the map has its own index into the coin state array. Yes, that means there's a maximum of 256 tile-based coins on a map. It seems enough.
When drawing the map edges when scrolling, I check each tile's type in a row or column to see if it's a coin tile. Then, I read the upper 8 bits for the coin index and then look up the coin state array to see if the coin has been picked up already. If the coin has not been picked up, I draw a coin tile. If if has, I draw an empty tile. When the plane passes over a coin, I change the coin's state in the coin state array and also directly change the background plane's coin tiles to empty ones.
That's the simple explanation. It's a little more complicated since there are actually 4 types of coin tiles, one for each corner of the 16 pixel by 16 pixel coin.
Added a little sparkly animation thing when picking up a coin.
As for the HUD, since I was implementing coins I figured I might as well show the player how many coins they picked up.
Goplanes Dev Video 012:
Added the beginnings of a in-game hud and coin pick up items.
I wanted to add coins so that the player can have a reward for exploring a map. Also, since maps will be pretty large, it'll help the player navigate around, since coins can also lead the player to interesting spots and goals. Similar to how coins are used in the Super Mario Bros. games.
Coins are sprite based and tile based. Sprite-based coins are of a new kind of object called "pickups". That'll be used for power ups and similar items later.
Tile-based coins were a challenge. I had to come up with a solution to change the appearance of the tile map without 1) copying the large tile map to ram and 2) keeping memory usage as low as possible but 3) still have a lot of coins in a map.
Since every tile in rom was using 16 bits and I'm only really going to use 8 bits of them anyway (for a max of 256 tiles per background plane) , I've decided to use the upper 8 bits as tile type-specific data. Depending on the type of tile (non-solid, solid, coin), the upper 8 bits can be used for extra information. In the case of a coin-type tile, the upper 8 bits is an index into a array of coin states. Every coin in the map has its own index into the coin state array. Yes, that means there's a maximum of 256 tile-based coins on a map. It seems enough.
When drawing the map edges when scrolling, I check each tile's type in a row or column to see if it's a coin tile. Then, I read the upper 8 bits for the coin index and then look up the coin state array to see if the coin has been picked up already. If the coin has not been picked up, I draw a coin tile. If if has, I draw an empty tile. When the plane passes over a coin, I change the coin's state in the coin state array and also directly change the background plane's coin tiles to empty ones.
That's the simple explanation. It's a little more complicated since there are actually 4 types of coin tiles, one for each corner of the 16 pixel by 16 pixel coin.
Added a little sparkly animation thing when picking up a coin.
As for the HUD, since I was implementing coins I figured I might as well show the player how many coins they picked up.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm