KABOOM! Dev thread.
potatohead
Posts: 10,261
Edit: Renamed this one to reflect work in progress on KABOOM!
I've started work on this title. I have to say thank you to Cardboard, for his excellent dev blogging. It's great to see the process and know where I've gotta go (mostly)
For the video, I'm gonna try something different. Instead of building a sprite engine that just can place sprites anywhere, I'm gonna do one that makes use of sprite strips. A sprite strip runs the vertical length of the screen. In my case, they will run vertically, starting from below the top score scan lines, which are just gonna be character mode, like the 8x8 driver.
The primary advantage of the sprite strips is their deterministic nature. Essentially, they are always there, so the code can take advantage of that. I've a render table in the HUB, that will hold three values: background color (necessary to capture the look of the game on the 2600, sprite 0 x, sprite 1, x, and that's it. Moving things vertically means just moving them in the sprite strip. Placing them horizontally will be just setting a value.
Sprites are 8 pixels (two longs) wide, for a total of 400 longs to cover the area of the screen I need. They are gonna be just full-color one byte per pixel. There is plenty of RAM for that. I suppose if I can't fit KABOOM! into the Propeller, I'm in trouble!
Guess we will see how that goes...
I've run into a stupid SPIN problem though. Driving me nuts. Right now, I'm building the video driver and testing it with some simple demo code to provide working data to debug with. Add one piece, test it, add another, etc... The render table background attribute is done, that's the color change seen in the screen shots. Next up is getting the sprite strips running.
Just added a simple repeat loop to load some test data into the sprite strip HUB memory buffer When I do this, some of the font table gets overwritten and I don't know why! That test data needs to be refined, it was just literally the first pass to make sure nothing was getting over written, and it happened!
In the two screenies, you can see some pixels under the score in one, and not in the other. Basically, that's with the sprite test data repeat commented out. This has gotta be some basic SPIN memory allocation thing I'm missing.
Here's the demo code. I've attached the TV driver, as it's long. It does not do anything with the sprite data however. I was about to write it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 12/16/2007 5:56:29 AM GMT
I've started work on this title. I have to say thank you to Cardboard, for his excellent dev blogging. It's great to see the process and know where I've gotta go (mostly)
For the video, I'm gonna try something different. Instead of building a sprite engine that just can place sprites anywhere, I'm gonna do one that makes use of sprite strips. A sprite strip runs the vertical length of the screen. In my case, they will run vertically, starting from below the top score scan lines, which are just gonna be character mode, like the 8x8 driver.
The primary advantage of the sprite strips is their deterministic nature. Essentially, they are always there, so the code can take advantage of that. I've a render table in the HUB, that will hold three values: background color (necessary to capture the look of the game on the 2600, sprite 0 x, sprite 1, x, and that's it. Moving things vertically means just moving them in the sprite strip. Placing them horizontally will be just setting a value.
Sprites are 8 pixels (two longs) wide, for a total of 400 longs to cover the area of the screen I need. They are gonna be just full-color one byte per pixel. There is plenty of RAM for that. I suppose if I can't fit KABOOM! into the Propeller, I'm in trouble!
Guess we will see how that goes...
I've run into a stupid SPIN problem though. Driving me nuts. Right now, I'm building the video driver and testing it with some simple demo code to provide working data to debug with. Add one piece, test it, add another, etc... The render table background attribute is done, that's the color change seen in the screen shots. Next up is getting the sprite strips running.
Just added a simple repeat loop to load some test data into the sprite strip HUB memory buffer When I do this, some of the font table gets overwritten and I don't know why! That test data needs to be refined, it was just literally the first pass to make sure nothing was getting over written, and it happened!
In the two screenies, you can see some pixels under the score in one, and not in the other. Basically, that's with the sprite test data repeat commented out. This has gotta be some basic SPIN memory allocation thing I'm missing.
Here's the demo code. I've attached the TV driver, as it's long. It does not do anything with the sprite data however. I was about to write it.
CON
' Set up the processor clock in the standard way for 80MHz on HYBRID
_CLKMODE = xtal1 + pll16x
_XINFREQ = 6_000_000 + 0000
VAR
byte displayb[noparse][[/noparse]20] 'allocate display buffer in RAM
'for now, just one line of char mode GFX.
long render_tab[noparse][[/noparse]200] '190 longs to hold sprite render list
long sprite0[noparse][[/noparse]400] 'sprite 0 graphic data
long sprite1[noparse][[/noparse]400] 'sprite 1 graphic data
long index 'just an index...
long params 'The address of this array gets
'passed to TV driver.
OBJ
tv : "KABOOM_TV_04" 'the actual TV display driver
PUB start | c, o, d, p
params[noparse][[/noparse]0] := @displayb
params := @fonttab
params := @render_tab
params := $0008e03 'char mode colors, light yellow on grey
{
'Fill Sprites with test data *This is the offending piece of code*
c := 0
repeat index from 0 to 380
long [noparse][[/noparse]@sprite0] [noparse][[/noparse]index] := c
long [noparse][[/noparse]@sprite1] [noparse][[/noparse]index] := c
c := c + 1
}
'Build Render Table
repeat index from 0 to 189 * 4 step 4
byte [noparse][[/noparse]@render_tab] [noparse][[/noparse]index] := $ba 'set background color
byte [noparse][[/noparse]@render_tab] [noparse][[/noparse]index + 1] := $20 'set sprite 0 x pos
byte [noparse][[/noparse]@render_tab] [noparse][[/noparse]index + 2] := $40 'set sprite 1 x pos
byte [noparse][[/noparse]@render_tab] [noparse][[/noparse]index + 3] := $00 'unused at present
repeat index from 0 to 16 * 4 step 4
byte [noparse][[/noparse]@render_tab] [noparse][[/noparse]index] := $03 'set background color to light grey
'char mode (score) test mode
c := 0
repeat index from 0 to 20
c := c + 1 'display the characters in the font table in sequence
c := c & %00000111 'only 128 chars in the supplied font table.
byte [noparse][[/noparse]@displayb] [noparse][[/noparse]index] := c 'put them in the screen memory buffer
tv.start(@params) 'start the tv cog & pass it the parameter block
DAT
'font table for score in char mode
fonttab byte byte %00000000 ' '
byte byte %00000000
byte byte %00000000
byte byte %00000000
byte byte %00000000
byte byte %00000000
byte byte %00000000
byte byte %00000000
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 12/16/2007 5:56:29 AM GMT
720 x 540 - 219K
720 x 540 - 225K
Comments
On first look, is this correct? do you want to set params 3 times?
PUB start | c, o, d, p
params[noparse][[/noparse]0] := @displayb
params := @fonttab
params := @render_tab
params := $0008e03 'char mode colors, light yellow on grey
or should they be
PUB start | c, o, d, p
params[noparse][[/noparse]0] := @displayb
params := @fonttab
params := @render_tab
params := $0008e03 'char mode colors, light yellow on grey
Oh, and
repeat index from 0 to 20
should be
repeat index from 0 to 19
as you only have 20 bytes allocated not 21 [noparse]:D[/noparse]
Just getting the girls to bed, will have a better look after.
Baggers.
Looks like your post got stripped too. Hate that.
Well, it's not the simple repeat mistake. Would be too easy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
I'm not sure I understand exactly what's happening but...
I think the problem might be in the TV driver. Your font is 8x8, but that top strip is actually displaying 9 scan lines, the last of which is corrupted. Change
cmp line_loop, #183 wz
to
cmp line_loop, #184 wz
and the problem goes away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Really trying to fit video into just one COG. This is a VCS (Atari 2600) game after all. I think it's simple enough to just fit.
Both sprite strips are up and running, with each scan line of the strip placed horizontally according to it's entry in the render table.
Added VSYNC flag to keep drawing changes keyed to non-display times. Basically it's set to either one or zero, depending on whether or not the active screen is being drawn. The idea being to only make render table X position adjustments when not drawing, so objects don't tear when moving. This is a fast game, making that important, IMHO.
Sprite two overlays on top of sprite 1 just as it should, but the reverse is not there. Not sure I have to do that case to complete the game however. There really is only one overlay condition and that's when the bomb gets dropped by the bomber. Easy enough to just use the sprites in the right order and call it all good.
Video code is mostly unrolled, leaving about 50 or so longs left in the video cog. Lots of places to save on longs too, if necessary. Feeling good about that right now.
On the hybrid @96 Mhz, there remains plenty of compute time in the scan line. Gonna try it at 80Mhz tomorrow on HYDRA. I found this game special case where the background is really only a solid color, one where some sprite combining time can be saved. Another big savings was filling the scan line buffer with the next scan line background right after it gets consumed by the waitvid. Doing this right in the waitvid loop essentially frees up over scan and HSYNC time to get the sprite strips done.
If it runs at 80Mhz, I'm gonna go for it, clean up the video code and start on the game in SPIN. If not, then I'll punt, use two COGs for video, then continue.
Next up, simulated hardware collisions. Should be able to do these while combining the sprites into the scan line buffer. After that, the only thing left to do, from a video perspective, is to allow one or the other of the sprite strips to be doubled up to draw the paddle. It's that, or multiplexing for the case where the bomb is on the same horizontal line as the paddle.
In the screen shot, the two sprite strips are partially filled with bomb image data, and some solid color to test overlay, underlay conditions. Motion blur appears to be an artifact of my capture card. Gonna run this on a real TV tomorrow to verify VSYNC stuff is doing what it should.
I'll post up the in process, working code tomorrow. Not on that machine at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 12/23/2007 5:20:38 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
The good:
After chasing my tail, I've got a nice, frame locked display, 2600 style. Safety tip: Do not trust your capture card for this! Use a real TV.
The bad:
I thought I was gonna get to double up one sprite, but this appears to take a lot more instructions and time than I thought. (suggestions welcome on this, BTW)
So, I've two sprite strips in the video COG, and they work nicely, but that means either multiplexing the bomb and paddle, when they are vertically aligned, or something else... Gonna think on it for a while. There is room in the COG, so maybe there is a solution yet.
No new screenies at this time, but here is the code in progress I had forgotten to post eariler. Right now, it's hybrid @ 96. Haven't tested on an 80Mhz board yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 1/12/2008 9:10:40 PM GMT
Baggers.
Hey, what's depicted by your current forum image avatar?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
It's TRex, from 3D Monster Maze, ( ZX81 Classic Game ) Baggers is currently doing a remake,
you won't be disappointed when he releases it!
en.wikipedia.org/wiki/3D_Monster_Maze
Great work with Kaboom so far!
Regards,
Coley
Like Coley posted ( for me, as my PC didn't want to post, had to reboot, lol )
It's TRex from 3D Monster Maze on the ZX81 ( that's my Hybrid version running so far, that I took the photo from. )
I started two days ago, and have made the ZX81 display, made a 8bit BMP to ZX81 charmap grabber, and got TRex in, and the 3D Maze in, and you can run around it. TRex is static at the mo, and I haven't done the exit wall yet.
but that's hopefully sometime tonight, when I get some coding time after my girls go to bed.
But it's looking great so far [noparse]:)[/noparse]
Jim.
Probably should put this on another thread, but... maybe not!
I went ahead and dragged out my 2600 driving controller. Since this is a paddle game, joystick / keyboard input just isn't gonna work. My plan is to do mouse, or driving controller, or maybe paddle later after I build the R/C circuit necessary for that. Most people will have a mouse, and the combo driver works for that. Is there a distributable gamepad driver for HYBRID yet? I've got the HYDRA one for testing right now --don't really want to roll my own. My time at the moment is limited.
The 2600 driving controller is just like a joystick, but it's got an encoder for the rotation axis, and I think the button is the same as the joystick.
Rotate = 00, 10, 11, 01
I'm assuming I can just compare the current state to that table to get the direction. If the spin exceeds the sample rate, well...
Also, gonna do scan line multiplexing for now to deal with the three sprite per line case where bomb and paddle occupy the same vertical space. Want to just push one COG to the limit @ 96Mhz, and always wanted to see how the scan-line multiplexing worked out anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
as for the joypad you can use the hydra code, with the buttons changed, for up down left right, there's source in my games, manic miner, jetpac, etc.
I've mapped all NES_START,SELECT,B and A to firebutton 1 on joypads, that way, it's got maximum compatibility for one button players.
as for the controller, you might need to give it it's own cog and constantly read it, as rotating will be more than one bit per 50fps [noparse]:)[/noparse] but since you're only using one cog i'm sure you've enough to spare [noparse]:)[/noparse]
Baggers.
PS, I'll probably be posting a hybrid pre-release demo for 3D Monster Maze [noparse];)[/noparse]
·
Angular resolution is not so sweet [noparse]:([/noparse]
Went ahead and dropped in the HYDRA gamepad code. Worked just fine. Before doing anything significant, I just dumped the output of the read function into the character mode score lines. (quick 'n dirty on-screen debug) The #$^#$% thing is 4 bits / 90 degrees. I suppose it does say driving on it... but still. I expected more than that.
That means, 16 pixels @ 1 pixel per change / rotation of the controller. That's 10 turns to travel the screen, or 5 turns, if I round movement to every other pixel, for 80 unique positions. That's no big crime, but too much for interaction on this game, so that's out. IMHO, velocities would take care of that, however one would also lose the 1:1 relationship between movement and on-screen paddle position. Necessary for this title.
On the other hand, that does explain why this controller is just spot on for Indy 500! It's nearly a 1:1 mapping.
This really is just a driving type device. maybe a scrolling racer would make sense at some point? The controller would be perfect for that. Nice to know the thing works just fine.
That means mouse and paddle, with circuit, for now.
On that note, I think it's not possible to use the game ports for paddles. They work through the shift registers, meaning no output capability = no way to charge the cap. Am I wrong on that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Baggers.
IMHO, the inability to deal with a paddle is a pretty minor loss. Most systems didn't even offer them up. Overall pin savings with the shifters is more than worth the trade.
For now, it's the combo driver and mouse. Plenty good to continue with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
out of curiosity, is there / or has anyone done a combo mouse driver yet?
Baggers.
My oldest daughter once picked up this game, after watching me play (well, trance out on it) for a while. When you hit the groove, it's about 12 bombs per second! At that point, gameplay is automatic, one either reaches that state, or one doesn't. Took her a few tries, she put down the controller and walked off annoyed. Later on, I hear that 12 bombs / sec for a pretty long stretch! Sure enough, she's there, got the trance and just playing it for all it's worth! It's pretty hilarious to watch somebody's face and hand, when they are really into this game.
After that experience, she announced that game changed her a little. It's addictive and improves some skill she didn't know she had. Current gen kids really don't get that intense hand eye experience like we did. IMHO, that's one of the major draws toward retro gaming.
Anyway, over the years, she has asked to play the old VCS, from time to time, and that game is always one of the ones that gets played. The other knob type game regulars are WARLORDS and INDY 500.
Now that you mention it, I don't know if I've seen a combo driver with mouse. This one can be mouse only really. Fire it up, press the button to get the bombs started and that's it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Even played the Flash version, very fun...
Looking forward to the remake...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
One of those small track balls in stead of a mouse and my fingers don't have the speed to keep up with the game...
I need to try it again with a mouse to get a feel of it, but it would be a good starting point for the Hydra...
Or maybe hook up my SlikStik, http://www.slikstik.com/spinfeat.htm , this spinner is awesome for Mame and should work with the Hydra as well...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
I tried the spinner with the Flash Kaboom! version and it works great...
Then I hooked up the spinner to the Hydra and tried Ball Buster and it works great with the Hydra as well...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
I'm looking forward to your version potatohead [noparse]:)[/noparse]
BTW, Did you have any luck getting the third sprite in? for when the bomb comes down the side of the players catchers?
The multiplexing is a PITA, and rapidly turning into something I don't want to deal with. SPIN is fast enough, but it's just not warranted.
I'm liking the sprite strip idea, so that's likely to stay, but it appears I either need to just full on bitmap graphics this, or build a scan-line renderer using more than one COG. Wanted to put video into one COG, just because I thought it might fit. IMHO, the bitmap stuff isn't likely to yield that crisp, frame locked display this title is known for. That's why I avoided it early on. I think that's still out.
Gonna think on it a bit, make sure I don't have an option on the current code path, then build out the two cog approach. One attractive element of the single cog, was just building up the video screen, using whatever mode made sense. The downside was making some compromises and the multiplexing is just one too many. Not worth it to just say, "Hey, video is in one COG."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 1/15/2008 7:58:44 PM GMT
I know what you mean though, could you still do multiplexing, using the sprite strip, just have an offset + sprite image for each sprite each scanline.
Or, could you shring the 'hx' and start the TV display just that little bit later? giving you the extra time to finish the last sprite?
Just an idea.
Jim.
There is almost enough time for three sprite strips as it is right now. Reducing the screen area, reproduces the original look, so I like that period. It also might provide the time needed. Instruction space is a problem, but I've not re factored anything, and it's all unrolled for the sprites. Gonna go count some cycles and loop a few things that could use looping. I may well find cycles too. One COG video might happen yet. It's close...
I don't quite grok where you were headed with the first suggestion. Can you expand on that some, when you have time? Perhaps my idea of what needs to happen to multiplex is just too messy.
Edit, forget the multiplex idea. I'm either gonna be able to fit the third sprite strip in there, or just go two COGs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 1/16/2008 4:23:07 AM GMT
I've also found I reach a realism limit too. Games should be an escape. The graphics power today brings with it, way too many real world expectations. Blech... Give me interesting game worlds with fun rules and some texture to them. This can be done, but just isn't. I fear we are in some sort of rut. Always comes around though. Somebody will break the mold, and maybe then I'll snag a newer console.
DDR is just sweet! Haven't tried Guitar Hero, but I know I would like it. We've got the pad and a PS2. That gets played a lot. You can play on the controller, of course, but moving on the pad really hits the groove, even if one does look silly. A friend of my daughters brought this goofy singing game over too. It displays an easy to read scale, and has a pitch meter. Totally fun. Frankly, I spent a lot of time in HS, as a kid, learning the art of sight reading, intonation, resonance, volume management --most of the vocal stuff. That game would have been a most excellent learning tool. And it's eye-voice, which is very interesting. Social too, and that's what I like about many of the older paddle games. Human on human, in the game world, is always a treat.
One other mode, done by Ian (forget his last name), is a sort of zen thing, where one sits on an old Amiga Joy board, and tries to reach a state of perfect balance. That one is mind-body, and displays a graphic and some sound on the 2600, while you just sit on the pad and go zen. Fun concept. We need more of those. IMHO, great targets for the prop at some point, because there would be a mix of electronics and software. I want to try that one someday.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!