Jump to content
IGNORED

Dragon's Havoc - Side-Scrolling Shooter, Cartridge Available for Purchase and Demo available for download in thread!


Recommended Posts

Cartridge now available for purchase at the AtariAge store!

 

Demo available:

This demo goes to stage 6-1 and has the stage select automatically enabled. 

A "tour" build meant for folks to check out later parts of the game - so high scores are deactivated, and the final stages are kept for those curious enough to buy a physical cartridge for now ;)

DragonsHavoc_Dec_2022_Demo.bas.a78

DragonsHavoc_Dec_2022_Demo.bas.bin

 

(Demo that goes to stage 4-3, testing full score and lives counter onscreen)

DragonsHavoc_2_20_2022_Demo.bas.a78

DragonsHavoc_2_20_2022_Demo.bas.bin

 

DragonsHavocDemoDesert.thumb.png.6cb7770b5480cee176a1778bb41d4040.png

 

 

DragonsHavoc_2_17_2022_Demo.bas.a78 - Demo to Stage 4-3, sfx changes, minor bug fixes

DragonsHavoc_2_17_2022_Demo.bas.bin

 

DragonsHavoc_2_13_2022_Demo.bas.a78 - This demo goes to level 4-3, adds shield mechanic

DragonsHavoc_2_13_2022_Demo.bas.bin - binary of above

 

 

DragonsHavoc_2_4Demo_2022.bas.a78 - Various little adjustments to controls and graphics for rage/fury feedback

DragonsHavoc_2_4Demo_2022.bas.bin

 

DragonsHavoc_1_18_2021_Demo.bas.a78 - Bug fixes

DragonsHavoc_1_18_2021_Demo.bas.bin 

 

DragonsHavoc_12_31_2020b_Demo.bas.a78 - Start of a rage/fury meter

DragonsHavoc_12_31_2020b_Demo.bas.bin - binary of above file

 

DragonsHavoc_12_31_2020_Demo.bas.a78

DragonsHavoc_12_31_2020_Demo.bas.bin

 

That's right - As I finish Dragon's Descent and Dragon's Cache, I figured why not make them part of a loosely connected thematic trilogy of games?

 

 

Here's a build - this is just a tech test at this point, "as is", but I'm curious to see how it runs on different machines (and 7800 hardware).  Press the joystick button to transition from the parallax to the tile level:

DragonsHavocSunset_5_19_2020.bas.a78

DragonsHavocSunset_5_19_2020.bas.bin

 

I've been sitting on this one for a while, working on it when I'm not occupied by other things.  Some other folks have been posting the awesome stuff they've been working on recently, so I'm giving in to implicit peer pressure :) 

 

I'll warn everyone that there is a looooong way to go before this one is ready - One reason I didn't post this sooner is the fear that it will draw attention away from the other games I'm close to completion on.  I'm still not 100% sure I'll be able to pull off all the features I think I'll need/want, but that's why I'm doing these tests.

 

DragonsHavoc_5_19_2020_1.thumb.png.1bb83bf0f0289532acd81f206786ce95.png

 

This particular demo is trying to juggle parallax scrolling, data-based tile scrolling, strategic use of sprite flicker, swapping graphics blocks, two simultaneous players, targeted projectiles, and some other stuff...

 

The video capture seems to have not captured the full framerate - I'm using flicker for the projectiles, rendering half of them every other frame, so there are roughly twice as many projectiles during actual gameplay, at least in emulation - I'm curious to see how this looks on physical hardware.  MAME A7800 seems to stutter every few seconds, while BupSystem and RetroPie have a nice, steady framerate that makes the projectiles look OK.  I'm usually dead-set against using flicker normally (some folks make it work, I usually can't), but I can make an exception for projectiles if I can get them to look semi-decent.

 

I'm totally using the double buffer for this, and working on ways to manage multiple graphic blocks (which is why the background glitches midway through, I'm switching blocks as I switch scrolling modes).  I'll likely have a ton of questions on the finer points of juggling multiple graphics blocks, performance costs for various things, etc.

 

DragonsHavoc_5_19_2020_2.thumb.png.a39f2f3b84415ad0ec9b96ff294cad0a.png

 

The big things/questions I still need to implement/answer are proper collision detection, and implementation of enemy placement throughout a level - to say nothing of specific game features!  I have the mechanics sketched out, but I want to see what my technical (in terms of the machine and my own skill are).  These are things I more or less know how to do, the trick is to make sure they work on top of everything else going on...

 

...oh yeah, and the mechanics, levels, and story!  *These* I actually have a pretty concrete ideas for, but that's why I'm stress-testing the 7800 (and my own coding skills) at the moment, to see if I can do this particular game on this particular platform.

 

Special thanks to a ton of sources, particularly RevEng and others involved with 7800 homebrew and 7800Basic. Also, in this particular case, some code I fairly shamelessly took from this forum thread to start my experimentation with shmup projectile aiming.

 

 

Edited by Revontuli
  • Like 19
  • Thanks 1
Link to comment
Share on other sites

Very cool! I like it that your characters do not shoot dots. Always bothered me about atari games a little dot instead of an object thrown across the screen. Also your graphics and colors look good. There are so many great 7800 games coming out it feels like being young again and being excited to get the latest and greatest.  

Edited by Jinks
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Super spectacular, and thanks for the mention! I love that you made your homebrews a themed trilogy of games. ?

 

This WIP confirms it for me - the 7800 homebrew scene is totally on fire - and I mean that in the completely-awesome-with-no-dumpsters-in-sight way! ?

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

With double buffering, are the BG sprites 16x16?
I am curious as to how you managed the scrolling BG AND the wave of enemy sprites at the same time i nthe same zpone without glitching out.  I seem to be able to get one or the other but not both.  

 

  • Like 1
Link to comment
Share on other sites

5 hours ago, Revontuli said:

That's right - As I finish Dragon's Descent and Dragon's Cache, I figured why make them part of a loosely connected thematic trilogy of games?

 

 

I've been sitting on this one for a while, working on it when I'm not occupied by other things.  Some other folks have been posting the awesome stuff they've been working on recently, so I'm giving in to implicit peer pressure :) 

 

I'll warn everyone that there is a looooong way to go before this one is ready - One reason I didn't post this sooner is the fear that it will draw attention away from the other games I'm close to completion on.  I'm still not 100% sure I'll be able to pull off all the features I think I'll need/want, but that's why I'm doing these tests.

 

DragonsHavoc_5_19_2020_1.thumb.png.1bb83bf0f0289532acd81f206786ce95.png

 

This particular demo is trying to juggle parallax scrolling, data-based tile scrolling, strategic use of sprite flicker, swapping graphics blocks, two simultaneous players, targeted projectiles, and some other stuff...

 

The video capture seems to have not captured the full framerate - I'm using flicker for the projectiles, rendering half of them every other frame, so there are roughly twice as many projectiles during actual gameplay, at least in emulation - I'm curious to see how this looks on physical hardware.  MAME A7800 seems to stutter every few seconds, while BupSystem and RetroPie have a nice, steady framerate that makes the projectiles look OK.  I'm usually dead-set against using flicker normally (some folks make it work, I usually can't), but I can make an exception for projectiles if I can get them to look semi-decent.

 

I'm totally using the double buffer for this, and working on ways to manage multiple graphic blocks (which is why the background glitches midway through, I'm switching blocks as I switch scrolling modes).  I'll likely have a ton of questions on the finer points of juggling multiple graphics blocks, performance costs for various things, etc.

 

DragonsHavoc_5_19_2020_2.thumb.png.a39f2f3b84415ad0ec9b96ff294cad0a.png

 

The big things/questions I still need to implement/answer are proper collision detection, and implementation of enemy placement throughout a level - to say nothing of specific game features!  I have the mechanics sketched out, but I want to see what my technical (in terms of the machine and my own skill are).  These are things I more or less know how to do, the trick is to make sure they work on top of everything else going on...

 

...oh yeah, and the mechanics, levels, and story!  *These* I actually have a pretty concrete ideas for, but that's why I'm stress-testing the 7800 (and my own coding skills) at the moment, to see if I can do this particular game on this particular platform.

 

Special thanks to a ton of sources, particularly RevEng and others involved with 7800 homebrew and 7800Basic. Also, in this particular case, some code I fairly shamelessly took from this forum thread on to start my experimentation with shmup projectile aiming.

 

 

Incredible work! 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

5 hours ago, gambler172 said:

Hi Rev

any bin for this?

Looks great.

Thanks!  Added the files to the original post, and also here:

 

DragonsHavocSunset_5_19_2020.bas.bin

DragonsHavocSunset_5_19_2020.bas.a78

 

I'm curious to see if this actually works on physical hardware - MAME a7800 is pretty good about showing sprite limits, but I'm pulling a few tricks here, and would love to see how it looks on various monitors and TVs.

 

5 hours ago, fultonbot said:

With double buffering, are the BG sprites 16x16?
I am curious as to how you managed the scrolling BG AND the wave of enemy sprites at the same time i nthe same zpone without glitching out.  I seem to be able to get one or the other but not both.  

Hopefully I *did* manage it - I've only the emulator's word for it right now :)

 

For the background I'm using 7800Basic's implementation of character mode, "double wide," and a zone height of 16.  It's all mode 160A, so four colors per character tile (really per row, the way I'm doing things).  I'm planning on doing a longer post on my process, but I'll do a summary here:

 

There are two scrolling techniques I'm using - "parallax" and "tile map".  With parallax mode I shift rows of character tiles a certain amount, with tile map I read in data and update the level.  

Both modes have just 1 "screen" plus a 1-block margin worth of data at a time.  One trick I use is dividing this "screen" into two parts, but then have each part switch places when I actually plot the data to the screen.  Moving the the location of the division of the screen in one direction or another is how the scrolling happens.  For the tile map mode, I just need to update the column of tiles next to the division.

 

For the tilemap mode, I use "pokechar" to change the tiles I need - and I only need to update one column at a time, whenever the player scrolls enough to warrant seeing a new one.  "plotmap" actually gets the data in RAM to the screen, but I'm ultimately drawing whole background from 7800basic using just two plotmap calls for the tilemap mode, and 2x however many "layers" (i.e. rows) I'm using in parallax mode.  In practice, I think this a large part of what keeps the DLLs and objects-per-row to a manageable number, but anyone who knows more about MARIA and DLLs can interject here with their thoughts!

 

So that is how I draw the background.  From there, I'm trying to plot as many sprites as I can with the leftover graphical resources I have left - the sprites are also 4-color, and, using MAME a7800 as a guide I've been able to get the number of sprites you see in the demo (again, I'm wondering how it looks on an actual 7800...).  I'm pretty sure I need the double buffer just to have the time to process the sprites along with the scrolling background - My understanding of DLLs and MARIA is still not masterful, but with how I understand things, using the double buffer halves the number of objects per zone, but with a single buffer I don't have the CPU time to animate and draw everything. 

 

I also have a sort of catch-22 where I can increase the number of display objects by allocating extra dlmemory, but that takes away from the RAM I need to store the resulting increase in enemy data (location, velocity, and AI states, etc. etc.)  I'd accept any clarifications or advice here, but as far as the current state of my display lists/tiles/sprites, I think having 8-16 sprites able to be on the same row as a scrolling background should be enough for what I want do-that's about (or even more than) what the NES had to use for games like Gradius.  I'm just hoping I'll still have the CPU time to handle the rest of game logic on top of that...

 

I hope that helps - I was in glitch city for a while myself as I tinkered with sprites, character tiles, and double buffers.  While I like how it currently looks (especially if this behaves on 7800 hardware), I'd welcome any advice, especially if I'm missing something that could help performance, object count, etc.  

1 hour ago, SlidellMan said:

I have to say, you are getting better at not just programming, but sprite animation as well. I'll wait for you to finish the other two first before you get to work on this.

Thank you!  I've learned a lot about what the 7800 can do, which makes me a little more confident in gauging how much "budget" I have for colors, frames, etc.  

Edited by Revontuli
  • Like 5
Link to comment
Share on other sites

1 hour ago, Revontuli said:

 

Both modes have just 1 "screen" plus a 1-block margin worth of data at a time.  One trick I use is dividing this "screen" into two parts, but then have each part switch places when I actually plot the data to the screen.  Moving the the location of the division of the screen in one direction or another is how the scrolling happens.  For the tile map mode, I just need to update the column of tiles next to the division.

 

 

Cool!  4-color 16x16 sprites in 160A is where I landed too with doublebuffering turned on for a smooth frame-rate.  I  have the one-block margin (so it's 11 sprites across total, one off the screen to start).  However, with all of them moving, I can get about 2 extra sprites in the same zones before it glitches out.   I was just planning to use the moving BG on top and bottom as window-dressing and and not allow any other sprites into those zones, then use a static title map with save/restore screen to get more complex BG (that doesn't move).  

I'm very interested in what you mean by "split the screen in two parts".  Is this because the BG sprites 16 pixels blocks that repeat, so only have to move them 16 pixels to the left and then restart to get the illusion of motion?  I guess I'm not getting it.  

Sorry if my questions seem dumb.  I only (re)started with 7800 Basic a few weeks ago after playing around a bit a year ago,  and stupidly enough first newbie attempt is a horizontal shooter.

-Steve

Link to comment
Share on other sites

32 minutes ago, fultonbot said:

I'm very interested in what you mean by "split the screen in two parts".  Is this because the BG sprites 16 pixels blocks that repeat, so only have to move them 16 pixels to the left and then restart to get the illusion of motion?  I guess I'm not getting it.  

No problem - I find it hard to describe using text.  Here's a diagram:

 

ScrollingDiagram.thumb.png.a804f01967ed66e46b46c2f257048235.png

The diagram doesn't show the margin that would be partially onscreen (I might update the diagram, and use less-MSpainty arrows :P), but you might be able to see how you can just update tiles next to the division to complete the "scrolling over a larger stage" illusion.  This might not totally solve your issues, but this technique did help me manage a lot of things - including making sure I only needed 1 screen worth of RAM (plus a little margin). 

 

Again, my understanding of DLLs is still not what I want it to be, but I think this also means you're only drawing two "objects" per zone with the background, since objects can be fairly wide.  The benefit is that you don't have to spend as much CPU time updating the tiles - just a column's worth with if you're pulling from a data set.  The sunset background I use in the demo isn't changed at all!

  • Like 2
Link to comment
Share on other sites

28 minutes ago, Revontuli said:

 

The diagram doesn't show the margin that would be partially onscreen (I might update the diagram, and use less-MSpainty arrows :P), but you might be able to see how you can just update tiles next to the division to complete the "scrolling over a larger stage" illusion.  This might not totally solve your issues, but this technique did help me manage a lot of things - including making sure I only needed 1 screen worth of RAM (plus a little margin). 

 

Again, my understanding of DLLs is still not what I want it to be, but I think this also means you're only drawing two "objects" per zone with the background, since objects can be fairly wide.  The benefit is that you don't have to spend as much CPU time updating the tiles - just a column's worth with if you're pulling from a data set.  The sunset background I use in the demo isn't changed at all!

Okay, cool. I'll try it myself and see if I can get it to work.
How wide are your background tiles?
I hope you don't mind if I chime in once and a while and ask a few questions.
Oh, I can't wait to play your game!

-Steve

Edited by fultonbot
  • Thanks 1
Link to comment
Share on other sites

This is a really rough and raw video. 

Colors are more vibrant live than what is seen below. 

Regardless, wanted to give a chance for Revontuli to have something from real hardware to reflect upon:

 

 

*EDIT:  Yikes, the CRT moire is much more intense with the YouTube standard view window size.  Try blowing the above up full screen for a (slightly) better image. 

 

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, fultonbot said:

Okay, cool. I'll try it myself and see if I can get it to work.
How wide are your background tiles?
I hope you don't mind if I chime in once and a while and ask a few questions.

No problem, I hope it helps!  This approach seems to work for me, but it'll depend a lot on how you want to structure your project, and there are a lot of ways to scroll on the 7800.

In 7800Basic I'm using the "doublewide on" option, which makes character tiles 8 pixels wide.  I'm also using the default zone height of 16 pixels as well.

Also, keep in mind this method only really works horizontally when using 7800Basic.  Plotmaps are placed horizontally by pixel, but placed vertically by tile.  

I'll try and answer questions as best I can - there's a reason I put these in the "Programming" forum :)

 

 

Edited by Revontuli
Link to comment
Share on other sites

6 minutes ago, Trebor said:

This is a really rough and raw video. 

Colors are more vibrant live than what is seen below. 

Regardless, wanted to give a chance for Revontuli to have something from real hardware to reflect upon:

Awesome - thank you!!  

 

The dragons and scrolling seem to be working well.  How do the bullets look in person?  The footage shot seems to have them fading in and out, but I don't know if that's an artifact of being filmed, or the 7800 skipping sprites...The way I'm coding them now is drawing 4 bullets every other frame, hopefully resulting in around 8 faded/semi-transparent bullets perceived on the screen at any one time.

Link to comment
Share on other sites

1 minute ago, Revontuli said:

Awesome - thank you!!  

 

The dragons and scrolling seem to be working well.  How do the bullets look in person?  The footage shot seems to have them fading in and out, but I don't know if that's an artifact of being filmed, or the 7800 skipping sprites...The way I'm coding them now is drawing 4 bullets every other frame, hopefully resulting in around 8 faded/semi-transparent bullets perceived on the screen at any one time.

My pleasure...Thank *you*!

 

It's more flickering than fading in and out.  We're definitely losing frames between the capture -> conversion -> YouTube upload, unfortunately.

  • Thanks 1
Link to comment
Share on other sites

1 minute ago, Trebor said:

It's more flickering than fading in and out.  We're definitely losing frames between the capture -> conversion -> YouTube upload, unfortunately.

I figured, or rather hoped so.  My fear was that the images were being cut off due to objects-per-row limits being exceeded, but this looks to be performing much like the emulators on that front.

 

I'm hoping I can get away with using the flicker effect for the bullets - if I make them a fiery aesthetic and pay attention to their color, I'm hoping they will read more as "transparent" or "sizzling" instead of "budget 2600 shovelware" or "malfunctioning hypnotron" :)

 

This is all great - Knowing this demo runs properly on hardware makes me feel better moving forward with some other experiments.  I didn't want to build a larger game and then realize initial code wasn't working with the hardware!

 

 

 

  • Like 3
Link to comment
Share on other sites

1 hour ago, Revontuli said:

In 7800Basic I'm using the "doublewide on" option, which makes character tiles 8 pixels wide.  I'm also using the default zone height of 16 pixels as well.

Also, keep in mind this method only really works horizontally when using 7800Basic.  Plotmaps are placed horizontally by pixel, but placed vertically by tile.  

 

Oh, It did not register that you were using plotmap.  Duh!
So there are two plotmap to make-up a full screen and you are decrementing the x position of the map every time you move?
If the above is true, does it redraw the map on each frame?  Are you using save and restore.

Link to comment
Share on other sites

14 minutes ago, fultonbot said:

So there are two plotmap to make-up a full screen and you are decrementing the x position of the map every time you move?
If the above is true, does it redraw the map on each frame?  Are you using save and restore.

That's the basic idea - dividing it into two sections makes it "loop" or scroll rather elegantly. 

With the double buffer, One needs to clear and redraw the screen, restore won't work.  There is a tempo of using save, clearing, and flipping that you need to do with the double buffer, but I've found, if I'm strategic, that I have enough time to warrant clearing the screen each frame.

  • Like 2
Link to comment
Share on other sites

9 hours ago, Revontuli said:

That's the basic idea - dividing it into two sections makes it "loop" or scroll rather elegantly. 

With the double buffer, One needs to clear and redraw the screen, restore won't work.  There is a tempo of using save, clearing, and flipping that you need to do with the double buffer, but I've found, if I'm strategic, that I have enough time to warrant clearing the screen each frame.

Okay, that seems like cool technique!!  Nice work. 
I hope you don't mind if I try my hand at something similar.  For my horizontal shooter I want a slowly scrolling starfield behind a faster scrolling obstacle plane.  What you've uncovered here might solve it.  thanks so much!

Link to comment
Share on other sites

  • 2 weeks later...

While the hardware test already went through...

 

On 5/19/2020 at 7:54 AM, Revontuli said:

The video capture seems to have not captured the full framerate - I'm using flicker for the projectiles, rendering half of them every other frame, so there are roughly twice as many projectiles during actual gameplay, at least in emulation - I'm curious to see how this looks on physical hardware.  MAME A7800 seems to stutter every few seconds, while BupSystem and RetroPie have a nice, steady framerate that makes the projectiles look OK.

...I have a possible explanation for this. Hardware tests have shown Maria's NTSC timing is 263 scanlines long, which causes her rendering to be slightly slower than the 59.94 or 60Hz used by most other consoles or computer displays. BupSystem keeps the 263 scanline length but artificially cranks the speed up to a fixed 60Hz so there's less chance of tearing or skipping.

 

So A7800's speed is likely correct, but your computer's display is off sync from its updates which causes the stuttering.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...