Do you have something in the works for collision detection? For the moment it looks like the best bet is to compare sprite positions with each other and/or compare against 'known' positions for background screen elements to use the driver.
OBC, Cool glad you're liking it, and getting to grips with it. and yes, I'll do a print function.
trodoss, Joust looks brilliant [noparse]:)[/noparse] well done, loving the bits under the platforms [noparse]:)[/noparse] and yes, I was planning to do some sprite to sprite/background collisions etc.
Quick question, can we afford another Cog? so I can put the funcs in PASM for speed and pixel collisions, or should I do approximations in SPIN to save a cog?
Edit: PS, sorry for delays in replying in past few days, I've been down to London and Oxford in the past couple of days, so been AFK a LOT! [noparse]:([/noparse] or is that AFP [noparse]:)[/noparse]
Thanks! I like the look of the arcade version, and am trying to bring a litte of that to this game. The original, with it's 1-color sprites would not do the driver justice [noparse];)[/noparse]
I am working through some odd 'artificating' issues that have started occuring when I added elements like the ComboKeyboard object. Not discounting yet that it may be long-alignment issue somewhere in the code. I am sure I will find the cause sooner or later.
I would think another cog would work. 5 rendering cogs + 1 keyboard/joypad cog + 1 sound cog + 1 main(game)?
Only thing there is it's already 5 cogs for 80Mhz systems. 4 render + 1 tv driver I'll see what I can do to speed things up, maybe I could setup a collision stuff when it's render cogs are inactive? [noparse]:)[/noparse] ie top and bottom border time
Actually, I was thinking that I would start loading/saving my sprites from SD as part of the game.
We could cut the number of sprites in half and it wouldn't bother me.. Baggers has left us an easy adjustment for this.
Also, as promised, a quick pic of where I am at on Joust. Working out movement/timing right now (in the "rough draft" phase). Once I can get things in order I will start a "project" thread for it [noparse];)[/noparse] The GFX are a little different from the 1983 console version (because 1-color dosen't do the driver justice).
@Trodoss: Here's an idea for you.. Since we have so much sprite room, you should do two modes.. One that uses the
original 1-color sprites and the second that uses the enhanced sprites. [noparse]:)[/noparse]
Is it playable yet?????? are we there yet?? are we there yet?? [noparse]:)[/noparse] Joust was one of my favorites.
Baggers said...
Quick question, can we afford another Cog? so I can put the funcs in PASM for speed and pixel collisions, or should I do approximations in SPIN to save a cog?
Oldbitcollector said...
@Trodoss: Here's an idea for you.. Since we have so much sprite room, you should do two modes.. One that uses the
original 1-color sprites and the second that uses the enhanced sprites. [noparse]:)[/noparse]
Is it playable yet?????? are we there yet?? are we there yet?? [noparse]:)[/noparse] Joust was one of my favorites.
I would probably·just include the bitmap of the current GFX and have the 'alternate' (retro 1-color) versions that could be built.· I am using quite a bit of the definable characters actually.·
As far as 'playable'....·Right now the main characters (bird and rider)·can move around.· I have·am working on issues with·collision detection with the platforms, so there is not much yet.
Once I can get my issues resolved I will go ahead and start a project thread and post the code thusfar.· So, should be soon, but not yet.
I have one other thing that I will try this evening when I get home. I had a wild hare of testing colors of the 4 corners of where the sprite would move (with the background) to see if that location is a non-zero color. That would work much more elegantly than the current method (setting the background elements to align 8x8, and testing if the player's x and y would fall on that element in the grid).
If that does not work (or, if I cannot get it to work) I will certianly PM, or just post what I have (if the attachments do not work).
no probs [noparse]:)[/noparse]
you'll need to check more than the corners, if you don't align it to 8x8, because you could move left over the edge of the platform in the middle of the sprite, thus missing the collision
I don't look often in the Hydra Forum, because I don't have a Hydra. But this Thread is very interesting for me, because I had the same Idea of a Game Dev Kit, and work on it.
The Emulator CPU is written in Spin and still ways to fast. So I had to insert a Delay.
The problem is, that not all Games work. I have included 9 Games 3..4 works, 2..3 works with errors and the remaining don't work.
I decided to not waste more time to find the bug(s), because the games are very poor. But I have learnd a lot about simple game programming.
The attached ZIP contains the source and 9 games, perhaps somebody else will continue the Emulator.
I switched to Baggers 16 color driver and work on a Sprite engine.... I like that driver much more than the VCS, and a background and sprite editor is already programmed.
I think I will have a demo tomorrow.
Ariba, cool news, glad you like the 16 colour driver, and I'm looking forward to seeing the sprite engine [noparse];)[/noparse]
I'm going to bed soon, so will have at the Chip8 emu tomorrow [noparse]:)[/noparse]
I was going to send the code to you via PM, but it does not allow attachments.· If I can get the collision code figured out I think it should be ready for it's own "project thread."
I took out my collision detection code, as it was not working as well as I had hoped.· Also, a significant amount of debugging still needs to be done on the code (a little embarassing really), as the movements of the sprites/responsiveness is not really what I want for the game.
If you have time, and could come up with something (for collision detection) then that would be great!
@Ariba: Exactly the direction I'm thinking.. Neat stuff! On my weekend Propeller list!
@trodoss: I haven't had a chance to try your code (although I know it was meant only for Baggers) but
I appreciate the simplicity of what you've done. I would have burned twice the code for that!
Any chance I can twist your arm into helping with the game rules stuff when I get to that point?
I'm about 1/3 of the way into a simple sprite editor using the Atari video driver. I thought I'd have
more to show of it by now, but it's been an extremely hectic week.
Wish that Parallax sold "Propeller time". Is the one item I find myself short on these days! [noparse]:)[/noparse]
Yeah, now that would be a great thing to sell, if only we could get more, I bet it'd be expensive, since it's a sparce commodity lol, can't touch this, song springs to mind though [noparse]:D[/noparse]
Ariba, that Chip8 emu is great [noparse];)[/noparse]
trodoss, almost finished work for the day, will have a look at it soon.
@OBC,
If you get to a point and you need help, let me know and I will be more than happy to help as best as I can.
@Baggers,
No hurry. I figured it may take some thought/work, and appreciate any time/effort you can put into it.
If it would be any help (probably not) I could pass along what I had come up with. My challenge was that it was requiring a significant amount of bitwise manipulation to determine background position, and what was throwing me was that it was 5 bytes (40 bits), and then 3 additional bytes per line that had to be 'skipped'
If it was simple 1-byte x/y sort of thing I think I coiuld have gotten it to work.
Here's the first pass of the collision for you, I've almost commented it, but I'm off for an early bed tonight, I'm pooped, but wanted to get it to you.
basically there's a PUB called check_collision(x,y,height)
which returns 0 or 1
0 for no collision and 1 for a collision
it checks all background pixels in the height, and gets a mask for X and X+4 and X+7 to do a test on.
There's a bit in Main that checks the bird, and also checks the feet for platform and sets the border to a colour depending on what it's collision is
That should give you enough to play around with now [noparse]:)[/noparse]
Thanks! That should be just what I needed. Also, thanks for re-structuring the config a bit (since that was needed as well). I had not yet set up the NES pad config for Hybrid/Hydra.
Now, to correct those lingering issues... [noparse];)[/noparse]
It shows Sprites on an partly animated background.
Every pixel of the Background and the Sprites can have one of 16 different colors, they use
the same palette.
The attached pictures shows how the animation is drawn. On every Vertical sync a buffer
with the background is copied to the screen, and then the sprites are drawn over that.
This must be fast, so I have made an Assemby driver for that.
This uses 2 * 6 kByte RAM (for the buffer and the screen), but allows flickerless animation
of the background.
This driver also does a collision detection:
1 color of the sprites can be defined as transparent. And some colors of the screen can
set to be collision sensitiv. You set just a color limit, all lower color numbers are
not collision sensitiv, the higher are.
When a not transparent sprite pixel covers a screen pixel, which is collision sensitiv,
a collision is detected, and the covered screen color is returned.
So you can easy decide which object forced the collision, if you give theme different
colors.
All the pictures are made with my Paint program, parts of the background will look familiar [noparse];)[/noparse]
The Demo is a little playable game, you can move the Helicopter around with the cursor keys,
and get points if you touch the blue Ball. But be wary of the red Ball !
NOW i will add sound. I try it first with my MIDI synth and hope it fits in the Memory.
This concept has taken some interesting turns since I introduced it.
We now have a very nice onboard editor. (Thanks to much hard work by Rick)
We also have a very nice onboard character editor. (Trodoss)
We also have a very nice sound driver "SIDcog". (Ahle2)
and between the two of us. (Mostly trodoss) we seem to have a growing set
of somewhat "common" routines for creating games.
I can't seem to leave the 8x8 driver. It's ease of use for a novice (like me!) and
the addition of 20 columns (thanks Doug!) makes it beg for neat games to be created.
At the moment I could visualize a propeller program which had you checkmark
the types of gaming options you wanted and it would create a game skeleton
to work from.
Maybe there's some serendipity here - I've been secretly working on game hardware for the Prop, it's called El Jugador:
It's completely under the MIT License (THANKS BAGGERS!) and it's designed as an expansion to the Propeller Platform, so you can add other modules, like a battery pack, Prototyper, etc., or take it off and use the Propeller for something else.
Here are the connections: 2 x NES connectors
P23 Clk
P24 Latch
P25 Data1
P26 Data2
SD card
P0 Do
P1 Clk
P2 Di
P3 Cs
Video / Audio
P11 Mono Audio
Demoboard Video pinouts
It comes with an EEPROM pre-loaded with Baggers' SD bootloader so programming doesn't require a PropPlug. Of course, there's a propplug connection on the Propeller Platform.
I've been working on documentation for the past few days, it's not ready for release yet, but it's getting close. Not sure if it's a good fit for game kit you guys are working on, what do you think?
The 8x8 text driver(s) are fairly simple to work with [noparse];)[/noparse] It is kind of like playing a game on a grid, where you can only have one thing in one location at a time.
Provided that you had parameters like:
Main map
[noparse][[/noparse] vw ] visible width
[noparse][[/noparse] vh ] visible height
[noparse][[/noparse] pw ] physical width (where bigger than 1 screen)
[noparse][[/noparse] ph ] physical height (where bigger than 1 screen)
Main character:
[noparse][[/noparse] x ] characters wide
[noparse][[/noparse] y ] characters tall
[noparse][[/noparse] f ] frames of animation
can move in [noparse][[/noparse] d ] directions
[noparse][[/noparse] g ] uses 'gravity' (meaning, can character 'fall?') [noparse][[/noparse]Y/N]
Enemies:
[noparse][[/noparse] x ] characters wide
[noparse][[/noparse] y ] characters tall
[noparse][[/noparse] f ] frames of animation
can move in [noparse][[/noparse] d ] directions
[noparse][[/noparse] g ] uses 'gravity' (meaning, can enemies 'fall?') [noparse][[/noparse]Y/N]
That might be a good start to cover 'simple' games.
The 'El Jugador' (The Player) looks great! Certianly there are already a wealth of games on the Hydra forum that it could already work with. Getting screenshots/video with Dodgey Kong/Defender/JB-Wolf [noparse];)[/noparse] Those have a lot of 'flash' to them.
Using Demo Board-like pin definitions is a good idea, so that it isn't stepping on the Hydra's toes [noparse];)[/noparse]
I would think you would want to default to pin 10 for audio though, unless that is a way to 'further differentiate' it from other boards (?)
[noparse][[/noparse]Edit:] If you were planning a "version 2" of the board, you·might consider·putting a PS/2 connection. That could facilitate on-board programming eventually (which is what OBC is mentioning above), and gives another option for a 'controller.'··Advances with SphinxOS and·PrEditor may make on-board programming possible.
Comments
Do you have something in the works for collision detection? For the moment it looks like the best bet is to compare sprite positions with each other and/or compare against 'known' positions for background screen elements to use the driver.
trodoss, Joust looks brilliant [noparse]:)[/noparse] well done, loving the bits under the platforms [noparse]:)[/noparse] and yes, I was planning to do some sprite to sprite/background collisions etc.
Quick question, can we afford another Cog? so I can put the funcs in PASM for speed and pixel collisions, or should I do approximations in SPIN to save a cog?
Edit: PS, sorry for delays in replying in past few days, I've been down to London and Oxford in the past couple of days, so been AFK a LOT! [noparse]:([/noparse] or is that AFP [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I am working through some odd 'artificating' issues that have started occuring when I added elements like the ComboKeyboard object. Not discounting yet that it may be long-alignment issue somewhere in the code. I am sure I will find the cause sooner or later.
I would think another cog would work. 5 rendering cogs + 1 keyboard/joypad cog + 1 sound cog + 1 main(game)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
We could cut the number of sprites in half and it wouldn't bother me.. Baggers has left us an easy adjustment for this.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
@Trodoss: Here's an idea for you.. Since we have so much sprite room, you should do two modes.. One that uses the
original 1-color sprites and the second that uses the enhanced sprites. [noparse]:)[/noparse]
Is it playable yet?????? are we there yet?? are we there yet?? [noparse]:)[/noparse] Joust was one of my favorites.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Please do anything you can to save cogs...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Why? Join the fun.. [noparse]:)[/noparse] BTW, congrats on winning the Unofficial Halloween Contest. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
As far as 'playable'....·Right now the main characters (bird and rider)·can move around.· I have·am working on issues with·collision detection with the platforms, so there is not much yet.
Once I can get my issues resolved I will go ahead and start a project thread and post the code thusfar.· So, should be soon, but not yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Thanks for the offer!
I have one other thing that I will try this evening when I get home. I had a wild hare of testing colors of the 4 corners of where the sprite would move (with the background) to see if that location is a non-zero color. That would work much more elegantly than the current method (setting the background elements to align 8x8, and testing if the player's x and y would fall on that element in the grid).
If that does not work (or, if I cannot get it to work) I will certianly PM, or just post what I have (if the attachments do not work).
you'll need to check more than the corners, if you don't align it to 8x8, because you could move left over the edge of the platform in the middle of the sprite, thus missing the collision
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I don't look often in the Hydra Forum, because I don't have a Hydra. But this Thread is very interesting for me, because I had the same Idea of a Game Dev Kit, and work on it.
Here is the result of my first try. A CHIP-8 Emulator for the Propeller. A Programming language with this name must be implemented on the Propeller
en.wikipedia.org/wiki/CHIP-8
www.pdc.kth.se/~lfo/chip8/CHIP8.htm Description of the instruction set and games
www.elephantsneverforget.co.uk/rg/chip8.html On line Emulator
The Emulator CPU is written in Spin and still ways to fast. So I had to insert a Delay.
The problem is, that not all Games work. I have included 9 Games 3..4 works, 2..3 works with errors and the remaining don't work.
I decided to not waste more time to find the bug(s), because the games are very poor. But I have learnd a lot about simple game programming.
The attached ZIP contains the source and 9 games, perhaps somebody else will continue the Emulator.
I switched to Baggers 16 color driver and work on a Sprite engine.... I like that driver much more than the VCS, and a background and sprite editor is already programmed.
I think I will have a demo tomorrow.
Andy
I'm going to bed soon, so will have at the Chip8 emu tomorrow [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I was going to send the code to you via PM, but it does not allow attachments.· If I can get the collision code figured out I think it should be ready for it's own "project thread."
I took out my collision detection code, as it was not working as well as I had hoped.· Also, a significant amount of debugging still needs to be done on the code (a little embarassing really), as the movements of the sprites/responsiveness is not really what I want for the game.
If you have time, and could come up with something (for collision detection) then that would be great!
--trodoss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
@trodoss: I haven't had a chance to try your code (although I know it was meant only for Baggers) but
I appreciate the simplicity of what you've done. I would have burned twice the code for that!
Any chance I can twist your arm into helping with the game rules stuff when I get to that point?
I'm about 1/3 of the way into a simple sprite editor using the Atari video driver. I thought I'd have
more to show of it by now, but it's been an extremely hectic week.
Wish that Parallax sold "Propeller time". Is the one item I find myself short on these days! [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Ariba, that Chip8 emu is great [noparse];)[/noparse]
trodoss, almost finished work for the day, will have a look at it soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
If you get to a point and you need help, let me know and I will be more than happy to help as best as I can.
@Baggers,
No hurry. I figured it may take some thought/work, and appreciate any time/effort you can put into it.
If it would be any help (probably not) I could pass along what I had come up with. My challenge was that it was requiring a significant amount of bitwise manipulation to determine background position, and what was throwing me was that it was 5 bytes (40 bits), and then 3 additional bytes per line that had to be 'skipped'
If it was simple 1-byte x/y sort of thing I think I coiuld have gotten it to work.
Here's the first pass of the collision for you, I've almost commented it, but I'm off for an early bed tonight, I'm pooped, but wanted to get it to you.
basically there's a PUB called check_collision(x,y,height)
which returns 0 or 1
0 for no collision and 1 for a collision
it checks all background pixels in the height, and gets a mask for X and X+4 and X+7 to do a test on.
There's a bit in Main that checks the bird, and also checks the feet for platform and sets the border to a colour depending on what it's collision is
That should give you enough to play around with now [noparse]:)[/noparse]
Jim.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
Thanks! That should be just what I needed. Also, thanks for re-structuring the config a bit (since that was needed as well). I had not yet set up the NES pad config for Hybrid/Hydra.
Now, to correct those lingering issues... [noparse];)[/noparse]
It shows Sprites on an partly animated background.
Every pixel of the Background and the Sprites can have one of 16 different colors, they use
the same palette.
The attached pictures shows how the animation is drawn. On every Vertical sync a buffer
with the background is copied to the screen, and then the sprites are drawn over that.
This must be fast, so I have made an Assemby driver for that.
This uses 2 * 6 kByte RAM (for the buffer and the screen), but allows flickerless animation
of the background.
This driver also does a collision detection:
1 color of the sprites can be defined as transparent. And some colors of the screen can
set to be collision sensitiv. You set just a color limit, all lower color numbers are
not collision sensitiv, the higher are.
When a not transparent sprite pixel covers a screen pixel, which is collision sensitiv,
a collision is detected, and the covered screen color is returned.
So you can easy decide which object forced the collision, if you give theme different
colors.
All the pictures are made with my Paint program, parts of the background will look familiar [noparse];)[/noparse]
The Demo is a little playable game, you can move the Helicopter around with the cursor keys,
and get points if you touch the blue Ball. But be wary of the red Ball !
NOW i will add sound. I try it first with my MIDI synth and hope it fits in the Memory.
Andy
Ariba, Excellent demo [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
We now have a very nice onboard editor. (Thanks to much hard work by Rick)
We also have a very nice onboard character editor. (Trodoss)
We also have a very nice sound driver "SIDcog". (Ahle2)
and between the two of us. (Mostly trodoss) we seem to have a growing set
of somewhat "common" routines for creating games.
I can't seem to leave the 8x8 driver. It's ease of use for a novice (like me!) and
the addition of 20 columns (thanks Doug!) makes it beg for neat games to be created.
At the moment I could visualize a propeller program which had you checkmark
the types of gaming options you wanted and it would create a game skeleton
to work from.
Thoughts?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Maybe there's some serendipity here - I've been secretly working on game hardware for the Prop, it's called El Jugador:
It's completely under the MIT License (THANKS BAGGERS!) and it's designed as an expansion to the Propeller Platform, so you can add other modules, like a battery pack, Prototyper, etc., or take it off and use the Propeller for something else.
Here are the connections:
2 x NES connectors
P23 Clk
P24 Latch
P25 Data1
P26 Data2
SD card
P0 Do
P1 Clk
P2 Di
P3 Cs
Video / Audio
P11 Mono Audio
Demoboard Video pinouts
It comes with an EEPROM pre-loaded with Baggers' SD bootloader so programming doesn't require a PropPlug. Of course, there's a propplug connection on the Propeller Platform.
I've been working on documentation for the past few days, it's not ready for release yet, but it's getting close. Not sure if it's a good fit for game kit you guys are working on, what do you think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!
Gadget Gangster - Share your Electronic Projects
Provided that you had parameters like:
Main map
[noparse][[/noparse] vw ] visible width
[noparse][[/noparse] vh ] visible height
[noparse][[/noparse] pw ] physical width (where bigger than 1 screen)
[noparse][[/noparse] ph ] physical height (where bigger than 1 screen)
Main character:
[noparse][[/noparse] x ] characters wide
[noparse][[/noparse] y ] characters tall
[noparse][[/noparse] f ] frames of animation
can move in [noparse][[/noparse] d ] directions
[noparse][[/noparse] g ] uses 'gravity' (meaning, can character 'fall?') [noparse][[/noparse]Y/N]
Enemies:
[noparse][[/noparse] x ] characters wide
[noparse][[/noparse] y ] characters tall
[noparse][[/noparse] f ] frames of animation
can move in [noparse][[/noparse] d ] directions
[noparse][[/noparse] g ] uses 'gravity' (meaning, can enemies 'fall?') [noparse][[/noparse]Y/N]
That might be a good start to cover 'simple' games.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
The 'El Jugador' (The Player) looks great! Certianly there are already a wealth of games on the Hydra forum that it could already work with. Getting screenshots/video with Dodgey Kong/Defender/JB-Wolf [noparse];)[/noparse] Those have a lot of 'flash' to them.
Using Demo Board-like pin definitions is a good idea, so that it isn't stepping on the Hydra's toes [noparse];)[/noparse]
I would think you would want to default to pin 10 for audio though, unless that is a way to 'further differentiate' it from other boards (?)
[noparse][[/noparse]Edit:] If you were planning a "version 2" of the board, you·might consider·putting a PS/2 connection. That could facilitate on-board programming eventually (which is what OBC is mentioning above), and gives another option for a 'controller.'··Advances with SphinxOS and·PrEditor may make on-board programming possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
Post Edited (trodoss) : 2/8/2010 9:53:41 PM GMT