Shmup console, give me your specs EDIT: *PICS*

mice · Post by **mice** » Sat Aug 13, 2005 3:49 pm

So, I'm thinking about putting some (cheap FPGA) HW together to create a small shmup-console with some sort of SDK for it.

Been doing some thinking about it for a while and this is what I've come up with:

Videocard:
* 224x160, tateable display.
* 2 layers of bkg, tile-based (thinking about 32x32 tile size)
* 1 text layer
* 16bit truecolor, no palettes, or?
* sprites, a lot of them. zoom and rotation support...
* (ver 0.1 will have VGA output)

Input:
* Arcade stick, 8-way, 3 buttons
* some kind of storage...USB mem? Too expensive?

So, what's your thoughts? And what is your dream-specs for a shmup-console?

Any inut appreciated!
Cheers!
((mice

mrMagenta · Post by **mrMagenta** » Sun Aug 14, 2005 12:48 am

hum, i don't quite get what the formfactor of your setup would be. are we talking about a mini-arcade? then again.. 224x160 doesn't have to mean pixels (close to one of GBAs resolutions)? i checked your website and looked at what you're doing.. so you could mean pixels.. which would be cool, but it would clutter very quickly with a lot of sprites.

on a serious note, your idea sounds cool.
have you read about the xgamestation, the build-it yourself open 16-bit game console? http://www.xgamestation.com/

btw. can i play any of the games on your site on my panasonic x200?

simma lungt

ED-057 · Post by **ED-057** » Sun Aug 14, 2005 5:47 am

I would guess that most people's "dream specs" are beyond the abilities of a cheap FPGA.

So tell us, what are the limitations? What hardware do you want to put inside the FPGA and what (if any) could go outside of it?

224x160 (scan-quadrupled?) is awfully low res for VGA, and I think 32x32 tiles are too big for that kind of resolution.

landshark · Post by **landshark** » Sun Aug 14, 2005 7:52 am

I thought an FPGA was simply a chip that you copy an image into to perform operations. I don't think they hold hardware.

mice · Post by **mice** » Sun Aug 14, 2005 7:55 am

Never heard of the xgamestation, could be what I'm trying to do. But their site seems to be having problems so I can check it out. Will see what that is about later.

mrMagenta: WAP into wap.akatora.se/a/a.wml and download it. If I'm not mistaken, I think the screen of the x200 is to small. But let me know how it turns out. Thx!

Yes, the 160px X 224px screen might get cluttered pretty fast...and where is the problem in that?

I would guess that most people's "dream specs" are beyond the abilities of a cheap FPGA.

True. I should have given you the limitations.

So tell us, what are the limitations?

As you were thinking, my idea was that all of it should get into the fpga, except for the storage rom/ram.
I was thinking about a fpga with about 500k switches.

224x160 (scan-quadrupled?)

I was thinking that the gamefield of 160x224 (or 224x160 in tate or horizontal-shmup mode) should be V/H-centered on screen. And a tilesize of 32x32 would get 5x7 (or 6x8 for 8-way scrolling) on-screen tiles, perfectly small memory-wise and for scroll-update-time...was my inital thought about it. Having a tilesize of 8x8 would mean that the tile-map would get 16 times as big.

The general idea of the project is that the shmup-engine would be built into the fpga as well.

The SDK environment having some "simple" scripting language /w compiler (for object movement) and editors to generate everything that would be needed by the games.
No real programming needed, just producing different kinds of data-files. (Which would be produced by real programming as well, but you know what I mean...)

Thoughts?
((mice

TGK · Post by **TGK** » Sun Aug 14, 2005 4:34 pm

I just read through the post, and though it sounds like a really interesting project, I can't help but wonder.

Did you consider a pc-based solution yet?

That was how the Xbox succeeded, and I strongly believe that it was a good idea (I have no bias for or against Microsoft). Why? just simply easier to program for, easier to get hardware, architecture is more or less well known, cheap...

TGK · Post by **TGK** » Sun Aug 14, 2005 4:40 pm

It also a allow for some unorthodox but powerful display options too

Like having OpenGL as the underlying display engine, OAL for sound, Ogre for a prebuilt, easy graphics API...

By the way, I was kinda drunk (from sickness, not party) when I posted that last post, I mean "Linux-based" not windows.

You can tune a copy of Linux until it runs nothing but the absolute necessary, making it extremely efficient.

Now add in a P3 processor and 256 MB of main memory, and 128 Mb of video memory

EDIT: now that I'm entirely sober, I realize that I actually mean "PC-based", the choice of OS doesn't really matter much, and only is a matter of what available for the lowest cost.

mice · Post by **mice** » Sun Aug 14, 2005 6:48 pm

I hear you TGK, but wouldn't it be soooo cool to have it all on a single chip?

And I just saw this...doh!
http://www.jbrain.com/vicug/gallery/c64dtv

Imagine something similiar, but with an arcade-stick-setup and a USB port for the games, and it could only run shmups...
And shmups that shmupers (is that a word!?) could "easily" do themself.

Or?
((mice

mrMagenta · Post by **mrMagenta** » Sun Aug 14, 2005 10:47 pm

that's sort of what i'm hoping for with the next gp32, an open platform that is easy enough for homebrew stuff to thrive, yet powerful enough for sprite heavy shmups. those game in joystick-packs are cool.

the problem would be in getting a userbase. if the system could double as an USB arcade controller and it would be easy to port stuff to it, for instance if you're using the SDL library, then i would want one!.. well atleast if it looked something like this: http://www.byrdo.org/images/Arcade%20St ... to%202.jpg

..but with a shmup motif.

ED-057 · Post by **ED-057** » Mon Aug 15, 2005 3:42 am

Can you put a 68000 CPU in there or is that too much? Then have a dozen or so PCM audio channels, 2MB of RAM on the outside, and a USB port (or maybe even some kind of IDE port to allow for HDD, CD, or compact flash) to load games from. Go with a 320x240x60hz display, then for video generation Keep a pair of buffers inside the chip to render the gfx for each scanline to, and keep the sprite attributes table in there also. Then read all other gfx data from external RAM as it is needed.

The C64DTV is just a tweaked C64 so the specs are relatively low for that. Jeri said that when she was designing it her employers kept nagging her to keep things small so it could be manufactured as cheaply as possible. Are you planning on using your shmup-chip for something that would have these kind of cost concerns perhaps?

mice · Post by **mice** » Mon Aug 15, 2005 12:03 pm

I'm totally sold on the shmup-in-a-joy idea now. Can't concentrate on anything else...

And especially having a stick, more or less exactly, like in that photo.

could double as an USB arcade controller

That's a really good idea, isn't it?

And getting a userbase for something like this, might be tough, but with a good launch-game or two, it might get some attention. Wouldn't it?

Are you planning on using your shmup-chip for something that would have these kind of cost concerns perhaps?

Well, I wasn't until now. So, I guess the 68000 is out of the window.
And I didn't think about sound at all until you mentioned it. Gotta go surfing for a decent and, now, cheap sound-chip.

I think I'm actually going to try this out.

So, anyone want to name the shmup-in-a-stick idea?

Cheers!
((mice

ED-057 · Post by **ED-057** » Tue Aug 16, 2005 10:45 pm

And I didn't think about sound at all until you mentioned it. Gotta go surfing for a decent and, now, cheap sound-chip.

Yamaha makes some soundchips that go in cellphones and the like, they have PDFs on their site that detail the features too.

So, anyone want to name the shmup-in-a-stick idea?

I think you need a controller port because I'm no good with a stick

AntiPasta · Post by **AntiPasta** » Wed Aug 17, 2005 8:30 pm

Well, some suggestions:

- RAM must be FAST, or at least part of it (think GBA's IWRAM or PSX' scratchpad)
- allow framebuffers and tiles/sprites simultaneously, if possible, allow software selection of "true" sprites and tiles (get superimposed on whatever video signal and don't appear in framebuffer) or blit sprites (are written to VRAM without CPU intervention)
- 8 bit palettized and 16 bit RGB modes, some effects are hard to pull off without pallette and vice versa
- enough CPU registers (if you decide to go for a Von Neumann-style CPU)
- don't forget sound

mice · Post by **mice** » Thu Aug 18, 2005 7:40 am

Yamaha makes some soundchips...

Thanks, I'll check them out asap.

- RAM must be FAST, or at least part of it (think GBA's IWRAM or PSX' scratchpad)
- allow framebuffers and tiles/sprites simultaneously, if possible, allow software selection of "true" sprites and tiles (get superimposed on whatever video signal and don't appear in framebuffer) or blit sprites (are written to VRAM without CPU intervention)
- 8 bit palettized and 16 bit RGB modes, some effects are hard to pull off without pallette and vice versa
- enough CPU registers (if you decide to go for a Von Neumann-style CPU)

I was thinking about doing a shmup-engine in there as well, then everything of the above would be transparent to the developer. Or would you really like to program this sort of thing yourself?

That's my main concern at the moment.
So, please vote.

Option A: (Standard console)
- Some CPU, with C compiler and documented asm.
- Video card with blitter/tiles/sprites in different layers, more or less as stated by AntiPasta. Reachable through documented registers.
- Sound card. Reachable through documented registers.

Option B: (Shmup-only-console)
- A Shmup-only engine, controlled through an easy-to-learn language (C-like but more like a script) and with easy-to-use editors for most of it.
- (With video and sound cards, but totally inaccessible to the developer)

With option A, any type of game could be possible...which would make the name shmup-in-a-joy strange.

With option B, only shmups could be made but with a clever scripting-language, the games could be made quite different from each other.

Personally, Option A would be a bit simplier to implement, but option B would be much more interesting for people wanting to do their own shmups really fast. Like me...

Cheers!
((mice

mrMagenta · Post by **mrMagenta** » Thu Aug 18, 2005 3:05 pm

i'd love something in the middle of A and B, sort of like gamemaker. it would be a lot more work for sure, but it could be scalable and have a flexible learningcurve to appeal to beginners as well as more jaded programmers. it would be c-like scripting but with advanced functions available to those who want to control screen drawing, collissions, game mechnics etc. in detail. if it gets too low-level it wouldn't be time-effective for most people to just thow together funny games and wonky ideas. the popularity of gamemaker is a testimony to the potential of this middleground between click-n-play and straight C programming.

btw. i was on BR-leksaker (swedish toystore) and was suprized at how many game-in sticks there are! street fighter 2 in stick, megadrive collections in pads, atari classics, fifa 96, track 'n' field etc.. only thing holding me back from buying (they sell at lower prices than console games) is that the sticks themselves look and feel REALLY CHEAP. if there would be a real Tac-2 with games in it, i wouldn't hesitate. so for shmup-in-stick i'd definetly go for arcade-class quality.

mice · Post by **mice** » Thu Aug 18, 2005 3:40 pm

I really need to get out more.
I just checked their homepage, and I definately have to get the SEGA one.

Guess there is a ton more of the kind coming now when the HW is so cheap.

i'd love something in the middle of A and B

I guess I have to do both then.

Good, then I have that out of my mind.

Regarding the blitter. Any request for function of it? Otherwise I'll go with a version of the Amiga one.
And the CPU will be something like the 68000, but a bit more RISCie.

Later!
((mice

TGK · Post by **TGK** » Thu Aug 18, 2005 3:47 pm

yea, I am personally psyched that somebody is attempting a arcade-class shmup-in-stick idea (assuming that's what Mice is aiming for), but I hesitate to cheer him on because I am not sure if he would get much back from doing it (that's why I was suggesting something PC-based, just for the sake of having an easier, potentially more end-user-friendly platform to work with).

But if you do this for fun first before profit, Mice, I cheer you on anyway.

kemical · Post by **kemical** » Thu Aug 18, 2005 6:57 pm

this is a cool idea, and I'd be interested in actually trying to dev something with it, if it wasn't all machine code / memory address crap.

people would probably want to mod their own controllers for it too, so maybe an optional barebones version would be good.

mrMagenta · Post by **mrMagenta** » Fri Aug 19, 2005 12:18 am

optional barebones sounds good. or some kind of kit-option where you can throw in buttons, stick and instructions for making the casing, also the option to thow in a module making it double as regular USB stick.. (if it could do both it would have its given place on the table and frequently remind me of developing something for it.)

i can see the conflict in what I would like from a product like this and what would make it profitable. personally i would favour arcade-grade buttons and stick and take the higher cost. that way it would be a pleasure to bring it with me and use in conjunction with my laptop and whatever television is at hand, and it would feel inspiring to run my own creations on it. but if it is to be more of a general 2d platform and appeal to the more casual buyers, a cheaper solution would certainly be more viable.

I don't know anything about blitters, processors etc. but if it will run in 320x240 or lower it would be all the more important to have the games run at 60fps (with loads of rotatable alpha blended sprites... wouldn't be wrong at all...)

mice · Post by **mice** » Sat Aug 20, 2005 10:20 am

But if you do this for fun first before profit, Mice, I cheer you on anyway

Thanks! I wouldn't do this if I didn't think it was fun. Imaging creating your own console. Or maybe you already have, and didn't think much of it

For me it would be a dream come true.

... if it wasn't all machine code / memory address crap.

So you mean you don't get a h**d on by reading functions of registers?!

I thought everyone was in to that kind of thing.

Regarding barebone-version.
How about these versions? : Gold, Dev, Plus and Normal.
- Gold would be the arcade stick version (hi-quality), doubling as a USB stick.
- Plus would be the arcade stick (cheap plastic crap).
- Normal would be just the console, with controller ports.
- Dev would be a Normal version but with CD's, manual and that sort of stuff.

On a progress note:
- I've just finished (99%) writing the CPU. I've named it the MT68x. Pretty much a 68000, but with a few operations striped off.
- The video card is coming along nicely...although there're a few things not even on the design-stage yet. It's sat at 320x240 /w 256 colors palette out of 16.8M colors. Color 0 of the palette is always the transparent one.
- I've completed the Blitter. Yay, something like 30 lines of code, must be missing something... But then again when 1 byte equals 1 pixel, there is no need for strange functions in it (like the Amiga blitters bit-shifting, for instance).

In a month (or two) I'll probably set up a site for it, trying to get a community going and a place for me to blog away.
That is, if I get the performance I aim for out of it...

Cheers!
((mice

landshark · Post by **landshark** » Sun Aug 21, 2005 5:46 am

Does your blitter support RLE'd sprites?

TGK · Post by **TGK** » Mon Aug 22, 2005 3:12 am

pardon my ignorance, but what does RLE stand for?

ED-057 · Post by **ED-057** » Mon Aug 22, 2005 5:46 am

RLE = run length encoding. It's a compression method that usually works by turning a string of 4+ identical bytes into a 3-byte code. And I agree, it is a good idea.

mice · Post by **mice** » Mon Aug 22, 2005 6:22 am

Does your blitter support RLE'd sprites?

No it doesn't. Never thought or heard about it before. As ED-057 said, it's a great idea! But come to think of it, there'll be no need to actually blit a sprite, there will be plenty of HW-sprites available.

And, on another note, have any of you encountered having the alpha-channel data in the palette before?
There'll be 16 customizable palettes in there, and the only way to support alpha (without extending the bytes/pixel ratio) is to have that data in the palette.
I haven't done much research of it, but I can't find any tools or references to this anywhere.

Your thoughts?
((mice

licksweets · Post by **licksweets** » Mon Aug 22, 2005 1:11 pm

I could recommend dsPIC dsp chips or BlackFin dsp chips for use as central CPU / GPU, as they both have normal processor commands as well as high speed maths operations. Writing a blitter or 3D renderer wouldn't be too difficult. Plus they are both designed for low component count, low voltage applications. I already started investigating making a small handheld console using some of these and a simple hi colour framebuffer, but alas time is a rarity for me as I'm deep in development of two games.

ED-057 · Post by **ED-057** » Tue Aug 23, 2005 6:17 am

mice wrote: And, on another note, have any of you encountered having the alpha-channel data in the palette before?

No, but if you were to include that kind of feature I'm sure the hacker types could figure out how to pull off all sorts of crazy gfx effects with it.

There'll be 16 customizable palettes in there, and the only way to support alpha (without extending the bytes/pixel ratio) is to have that data in the palette.

If you want alpha for the sake of transparency effects you could have an alpha value for each sprite or background layer, instead of having different alpha values for different colors in the palette.

mice · Post by **mice** » Tue Aug 23, 2005 7:24 am

There will be a alpha value for each of the sprites.
And I thought each tile should have their own alpha value as well, not just the layer.

Data for each tile:
- tile#
- palette#
- alpha-value
- properties (blend-type, flip_x,flip_y)

Data for each bkg-layer:
- coordinate (x,y,z) (X and Y are offset within one tile and Z is the draw-priority)
- (scale...only in design-stage, yet. Might make it or not.)

Data for each sprite:
- coordinate (x,y,z) (Where Z is the draw-priority)
- width, height
- source_adress
- pivot_x, pivot_y
- scale (factor, auto_z)
- rotation (0-255)
- alpha-value
- palette#
- properties (blend-type, flip_x,flip_y)

And I've set up so one can set the screen-background-color for each line or row as well.

Apart from the text-layer, this is it when it comes to the gfx card.

Did I miss anything important?
((mice

TGK · Post by **TGK** » Tue Aug 23, 2005 3:58 pm

I think per pixel alpha value for the sprites (like in a png file) would be more benefitial than tile alpha values, but may be that was what you meant and I misread it.

But if adding the alpha channel into the pallete is too hard, then just code a rule that allow not drawing one exact color on any sprite would suffice.

By the way I've never attempted making a console, but I know the amount of work that goes into it. I'm very interested to know the status of this project.

Anyhow, just a random thought that has bugged me for ages, I have seen game that "seems" to have pixel perfect collision detection. Do you think they just approximate with a lot of bounding boxes, or is there away to do decently fast per pixel collision?

mice · Post by **mice** » Wed Aug 24, 2005 2:33 pm

I think per pixel alpha value for the sprites (like in a png file) would be more benefitial than tile alpha values, but may be that was what you meant and I misread it.

Don't quite follow you here...but that's me in a nutshell.

PNG-files can't store alpha-values, can they? I know they can store a single transparancy color, but that's it, isn't it?
What I ment was that each sprite have their own alpha-value (so that you can fade the sprite away, for some reason).
Also in the palette of 256 colors (which there will be 16 of) there will be a alpha value for each color as well (so you can have a see-through-shadow of a tank in the sprite, for instance. as opposed to using two sprites, one for the tank and another for the shadow).

But if adding the alpha channel into the pallete is too hard, then just code a rule that allow not drawing one exact color on any sprite would suffice.

In the palette, I've hard-coded so that 'Color 0' will always be transparant (or, to put it in another way, has the alpha value set to '0')

By the way I've never attempted making a console, but I know the amount of work that goes into it. I'm very interested to know the status of this project.

There're a lot of things left. So far, the only thing in place is the CPU and a small test-bed for the background tiles.
I hope that by late next week, I will have the video-card-design done.
And, as I stated in my last post, in a month or two there will be enough done to actually have something to show.

Anyhow, just a random thought that has bugged me for ages, I have seen game that "seems" to have pixel perfect collision detection. Do you think they just approximate with a lot of bounding boxes, or is there away to do decently fast per pixel collision?

Nowdays, my guess is that it's all done with bounding boxes.
Once upon a time though, like in the C64-days, there were pixel-perfect collision detection available in HW.
I've given this some thought actually, but I think I'll leave it out of the HW.

mrMagenta · Post by **mrMagenta** » Thu Aug 25, 2005 11:15 am

this is really exiting stuff.

256 colors (which there will be 16 of) there will be a alpha value for each color as well

will this be a 0-255 range value?

also, will there be support for blending modes, like additive? making bullets additive etc? offcourse that might seem a bit overkill on 320x240 anyhow, but for explosions it is really effective. i'm not sure how this is done normally, if there is hardware accelleration for it or not, so maby i'm just out riding a bike.

btw. pngs can store a full alpha value, not just a transparency color

shmups.system11.org

Shmup console, give me your specs EDIT: PICS

Shmup console, give me your specs EDIT: PICS

Re: Shmup console, give me your specs