My first suggestion, was to change the pixel clock to a lower value, thus making the pixels smaller, and increasing the left and right borders, this is a LOT easier with the Parallax TV driver, as it re-calculates the numbers for you, you just change the 'hx' value in tvparams [noparse];)[/noparse]
I've not really used the simplentsc that much, as I wanted to use PAL and NTSC in my stuff, being in the UK.
Perhaps someone should do a DDR game [noparse]:)[/noparse] that would be great [noparse]:)[/noparse]
Hi Baggars. It's not difficult with the code I have now. All that timing is worked out, meaning a coupla changes to gain the time. I think that's gonna work. I also figured out what you meant by the offset. Nice tip in that I can probably prep the sprite data, then just dump it into the scan buffer twice! Some minor changes to the paddle image data should make this ok.
---->just a quick post to let people know I'm still alive. Dance Team comps are going right now, that eats a ton of time. It is time spent with my daughter though, so all good.
No screenies today, but I've got the offset working. That's three sprites for the bomb / paddle lines. (thanks for the hint Baggars!)
Gotta do some thinking about how things are masked and consider game states. I think what I have now will do the game nicely, but am not yet positive. It's sometimes nice to step away from a hunk of code and come back later. Also spending a bit of time today looking through some game play AVI's to work out bomb drop speed ramp ups, number of bombs dropped per session, bomber movement and such.
This game gets FAST. 13 or so bombs per second at the peak, it seems! At those speeds it's gotta be paddle or mouse. I suspect paddle only will work for the higher levels of game play. When I get that far, I'll provide a simple paddle interface circuit and maybe a little tester program for those who build one and want to just tune it in.
I designed a joystick for the Atari 2600 that emulates a paddle via digital pots, so you have 256 different positions. Then there are a bunch of modes of operation; absolute motion, accleration, and curve that controls how the virtual paddle moves as you move the joystick. Anyway, long story short, I was able to double my scores with my joystick since right/left was easier then rotate right left for speed and timing. Interestingly, when I tried cold turkey the paddle and joystick I could get better scores at first with the paddle, but once I learned how to overshoort, undershoot with the virtual joystick it was ok.
So moral of the story is if you put a little "controller" interface after the right/left that accelerates the position and decelerates the the gamepad will work well also. The only problem with the mouse is slipage, but definitely try and make a cool gamepad interface.
Small update: No new screenies just yet. Life is improving, and with that comes some more regular propeller time. Nice!! Nothing new to show, until stuff moves and displays properly.
I'm having trouble with the sprite offset. Basically, I'm outta either instructions or time in the COG. That means the @#$(&*$#% paddle isn't displaying as it should. (shifting and combining has to happen, even with the offset and that's the core of the trouble) I thought I had this, but I just don't. Didn't come up until testing paddle motion. Arrgh!!!!
On the positive front, I've got a Genesis game pad working. For game pad mode, I think scaling the paddle movement to be appropriate for the bomb drop rate will solve the problem of how to play this game with a gamepad. I'm just filing that here, for that part of things to come up soon. This will limit the player skill required to some range that makes sense. As the game speed ramps up, the human I/O will stay within gamepad range, without having this really touchy pad that overshoots in the lower speed levels, and does not quite keep up at the higher speeds. This game does 13 bombs per second at it's peak!
After battling with this last night, I realized I can work with words instead of bytes, to double up the pixels. I suspect this will bring down both instruction and time requirements to fit within the video COG. The paddle is double pixel resolution anyway, so that's where I'm focusing right now.
Other positives are sub-objects (or is that just objects? Hell if I know.) for bomber position, and animation. (happy, sad, stoic, etc...). Same for paddle, and almost done for the bombs.
Vblank latch working reliably now too. That means game logic and movement how happen between frames.
Learning a lot about sprites. Man, they take a LOT of instructions! This will be a 96 Mhz game, for sure. I thought building things on the fly would go better than it has. Clearly a frame buffer, with software sprites would just be cake. Learning a lot though, so it's all good. If this pixel doubling doesn't fly, then it's gonna go that route so I can move on to something else. The feeling of frame locked motion can be preserved, if it's all done in the VBLANK. Don't see a reason why it can't at this point, so I'm just being stubborn. I wanted the game to be small, but it's rapidly not being worth it. I've learned a ton, so it's really one more iteration on the double pixels. Some stuff to learn there. If it doesn't come up to snuff, I'll just do a frame buffer.
Wonder if it will draw fast enough to just have a single frame, with graphics in the Vblank? Might get to see.
While I'm dealing with that. I swear I saw a thread on how to read a potentiometer. The core of it is an R/C circuit, where either a pin is changed from low to high, or high to low, then counting happens to watch the transition. In the very near future, I think I'm gonna need a quick 'n dirty circuit for that. Any suggestions for a 1 Meg Ohm pot? That's the Atari value. I think most PC pots are 150Kohm or something like that.
Did I understand correctly that you have the Sega Genesis pad working?
Mind sharing how you are interfacing with the "74HC157"?
Any chance we could create a standard drop-in gamepad_drv from your solution?
I'm using it with the Hybrid board, and it just appears to work nicely with the modified nes driver somebody posted. Two of the buttons don't work yet, and I'm looking at that, but the DPAD and B button is just fine. I'll have to take it apart to see what the deal is with the other two buttons. Maybe I'm missing something, but doesn't the Genesis pad work like an Atari joystick does? I've used the things on an Atari before --err, I think I have!
Maybe we can do a drop in in any case. I'll have to look at the standard thread you posted up. I really like the Genny pads. Best of the lot, IMHO.
Also scored a metal case NES Advantage joystick controller! It's pretty sweet for the HYDRA. Has both players available with a switch on the top. Great for testing. Gotta say I like the DB9 interface way better than the NES one. At least now, I've got a nice controller to work with on that board.
(went thrifting this weekend looking to replace some retro gaming stuff. Lost my VCS and some goodies, like the $@(*%^@(*$^% trackball in my recent move.)
Hey Baggars, I had an idea I wanted to share with you. Since this is my thread, I can go off topic! Been thinking about different ways to drive video. (always) Anyway, somebody gave me a high-def plasma TV. Lots of fun with that thing. In the hunt for how all the inputs work, I discovered that component video can drive at many different scan rates, opening the door for higher resolution Propeller drivers, or really great NTSC ones.
My thought came back to using the COGs in tandem. Basically on Prop I, getting the PLLA counters to all mesh up is a PITA. I never did see any worthy success doing that, and had abandoned it, waiting for Prop II, where that's gonna happen easily enough. (can't wait for the nice HUD's and such that will be possible)
A monochrome display IS possible though, and that's where it all came together this weekend.
Say we use three COG's. One each for Luma, -R and -B. That would deliver a nice, high-color display with a lot of interesting options! Say it's also still just NTSC, because RAM on the prop is scarce.
On the mono channel, run a standard NTSC signal. No color burst, just pixels and intensities. Nice and simple, and easily capable of the full 720 lines most displays can resolve. Since we don't worry about colorburst, two other generators can run on the -R and -B channels, yielding a multi-color display.
Drive each one from it's own bitplane, and it's all very interesting where RAM is concerned. Could single buffer color, to save RAM, for example. Or bandwidth limit it, with fatter pixels, leaving the intensity sharp, or just pack in a nice amount of colors, with no wasted bits.
Only the Luma input needs to drive sync, meaning the color channels could run with a slightly modified video adder as well. Would be a bit shallow on greens and yellows, but nice on the rest.
For text, crank it up, and get a very nice and sharp hi-def graphics display too.
Just use three video circuits instead of one, and use the blanking time to move stuff, to take full advantage of all the COG's. VIC II display capabilities are likely well within this range, plus some extras! Three VBLANKS can get a lot of sprite work done. Combine that with tiles, and it might just be sweet.
Thought you might find that interesting, given all your excellent PROPGFX work.
I'm probably gonna go down this road sometime here soon. Thought it was a neat idea and was curious to hear what you think about it.
Hi potatohead, I'm just off to bed, but yeah, been there had a good think about doing it, now that PropGFX is complete codewise, I'll have a crack at doing component, unless you beat me to it, but yeah it's a great idea [noparse]:)[/noparse]
should be interesting what results we get out of it.
I was gonna do that instead of using SCART, when I found out US don't have SCART, but then realised it'd take three cogs up, so didn't.
but I do want to have a go at doing some kind of display, just to see what colours we can get out of it. [noparse]:D[/noparse]
Catch ya tomorrow, for more talkies [noparse]:)[/noparse]
Looks like the solution for this one is to cut the horizontal resolution of the paddle by two. That's only one shift case, and that will fit into the blanking time. For playability, this really won't impact the game, so I'm gonna rip out sprite0 code, and put this in it's place. (crosses fingers, or it's the $%(*&#$(%*& frame buffer)
Comments
My first suggestion, was to change the pixel clock to a lower value, thus making the pixels smaller, and increasing the left and right borders, this is a LOT easier with the Parallax TV driver, as it re-calculates the numbers for you, you just change the 'hx' value in tvparams [noparse];)[/noparse]
I've not really used the simplentsc that much, as I wanted to use PAL and NTSC in my stuff, being in the UK.
Perhaps someone should do a DDR game [noparse]:)[/noparse] that would be great [noparse]:)[/noparse]
---->just a quick post to let people know I'm still alive. Dance Team comps are going right now, that eats a ton of time. It is time spent with my daughter though, so all good.
More to come.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Gotta do some thinking about how things are masked and consider game states. I think what I have now will do the game nicely, but am not yet positive. It's sometimes nice to step away from a hunk of code and come back later. Also spending a bit of time today looking through some game play AVI's to work out bomb drop speed ramp ups, number of bombs dropped per session, bomber movement and such.
This game gets FAST. 13 or so bombs per second at the peak, it seems! At those speeds it's gotta be paddle or mouse. I suspect paddle only will work for the higher levels of game play. When I get that far, I'll provide a simple paddle interface circuit and maybe a little tester program for those who build one and want to just tune it in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
So moral of the story is if you put a little "controller" interface after the right/left that accelerates the position and decelerates the the gamepad will work well also. The only problem with the mouse is slipage, but definitely try and make a cool gamepad interface.
Andre'
Life is improving folks!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I'm having trouble with the sprite offset. Basically, I'm outta either instructions or time in the COG. That means the @#$(&*$#% paddle isn't displaying as it should. (shifting and combining has to happen, even with the offset and that's the core of the trouble) I thought I had this, but I just don't. Didn't come up until testing paddle motion. Arrgh!!!!
On the positive front, I've got a Genesis game pad working. For game pad mode, I think scaling the paddle movement to be appropriate for the bomb drop rate will solve the problem of how to play this game with a gamepad. I'm just filing that here, for that part of things to come up soon. This will limit the player skill required to some range that makes sense. As the game speed ramps up, the human I/O will stay within gamepad range, without having this really touchy pad that overshoots in the lower speed levels, and does not quite keep up at the higher speeds. This game does 13 bombs per second at it's peak!
After battling with this last night, I realized I can work with words instead of bytes, to double up the pixels. I suspect this will bring down both instruction and time requirements to fit within the video COG. The paddle is double pixel resolution anyway, so that's where I'm focusing right now.
Other positives are sub-objects (or is that just objects? Hell if I know.) for bomber position, and animation. (happy, sad, stoic, etc...). Same for paddle, and almost done for the bombs.
Vblank latch working reliably now too. That means game logic and movement how happen between frames.
Learning a lot about sprites. Man, they take a LOT of instructions! This will be a 96 Mhz game, for sure. I thought building things on the fly would go better than it has. Clearly a frame buffer, with software sprites would just be cake. Learning a lot though, so it's all good. If this pixel doubling doesn't fly, then it's gonna go that route so I can move on to something else. The feeling of frame locked motion can be preserved, if it's all done in the VBLANK. Don't see a reason why it can't at this point, so I'm just being stubborn. I wanted the game to be small, but it's rapidly not being worth it. I've learned a ton, so it's really one more iteration on the double pixels. Some stuff to learn there. If it doesn't come up to snuff, I'll just do a frame buffer.
Wonder if it will draw fast enough to just have a single frame, with graphics in the Vblank? Might get to see.
While I'm dealing with that. I swear I saw a thread on how to read a potentiometer. The core of it is an R/C circuit, where either a pin is changed from low to high, or high to low, then counting happens to watch the transition. In the very near future, I think I'm gonna need a quick 'n dirty circuit for that. Any suggestions for a 1 Meg Ohm pot? That's the Atari value. I think most PC pots are 150Kohm or something like that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Post Edited (potatohead) : 11/30/2008 8:28:18 PM GMT
Mind sharing how you are interfacing with the "74HC157"?
Any chance we could create a standard drop-in gamepad_drv from your solution?
Nice to see you working on this again!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Maybe we can do a drop in in any case. I'll have to look at the standard thread you posted up. I really like the Genny pads. Best of the lot, IMHO.
Also scored a metal case NES Advantage joystick controller! It's pretty sweet for the HYDRA. Has both players available with a switch on the top. Great for testing. Gotta say I like the DB9 interface way better than the NES one. At least now, I've got a nice controller to work with on that board.
(went thrifting this weekend looking to replace some retro gaming stuff. Lost my VCS and some goodies, like the $@(*%^@(*$^% trackball in my recent move.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Me too.
Hey Baggars, I had an idea I wanted to share with you. Since this is my thread, I can go off topic! Been thinking about different ways to drive video. (always) Anyway, somebody gave me a high-def plasma TV. Lots of fun with that thing. In the hunt for how all the inputs work, I discovered that component video can drive at many different scan rates, opening the door for higher resolution Propeller drivers, or really great NTSC ones.
My thought came back to using the COGs in tandem. Basically on Prop I, getting the PLLA counters to all mesh up is a PITA. I never did see any worthy success doing that, and had abandoned it, waiting for Prop II, where that's gonna happen easily enough. (can't wait for the nice HUD's and such that will be possible)
A monochrome display IS possible though, and that's where it all came together this weekend.
Say we use three COG's. One each for Luma, -R and -B. That would deliver a nice, high-color display with a lot of interesting options! Say it's also still just NTSC, because RAM on the prop is scarce.
On the mono channel, run a standard NTSC signal. No color burst, just pixels and intensities. Nice and simple, and easily capable of the full 720 lines most displays can resolve. Since we don't worry about colorburst, two other generators can run on the -R and -B channels, yielding a multi-color display.
Drive each one from it's own bitplane, and it's all very interesting where RAM is concerned. Could single buffer color, to save RAM, for example. Or bandwidth limit it, with fatter pixels, leaving the intensity sharp, or just pack in a nice amount of colors, with no wasted bits.
Only the Luma input needs to drive sync, meaning the color channels could run with a slightly modified video adder as well. Would be a bit shallow on greens and yellows, but nice on the rest.
For text, crank it up, and get a very nice and sharp hi-def graphics display too.
Just use three video circuits instead of one, and use the blanking time to move stuff, to take full advantage of all the COG's. VIC II display capabilities are likely well within this range, plus some extras! Three VBLANKS can get a lot of sprite work done. Combine that with tiles, and it might just be sweet.
Thought you might find that interesting, given all your excellent PROPGFX work.
I'm probably gonna go down this road sometime here soon. Thought it was a neat idea and was curious to hear what you think about it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
should be interesting what results we get out of it.
I was gonna do that instead of using SCART, when I found out US don't have SCART, but then realised it'd take three cogs up, so didn't.
but I do want to have a go at doing some kind of display, just to see what colours we can get out of it. [noparse]:D[/noparse]
Catch ya tomorrow, for more talkies [noparse]:)[/noparse]
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·