Hi,
I've found the vector demo in video mode 6 and I ask me is it possible to realise an asteroid game (close to the original game) with vectors in this mode?
http://www.retromagazine.eu/retro/asteroids/
-Harty
Asteroids
Asteroids
Life's too short to remove usb safely
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Re: Asteroids
Admittedly I've only played asteroids a little, and not recently....and I've never used mode 6...but, my instinct tells me it is possible maybe needing a shortened screen that I'm always gung-ho for(a lot of pixels to calculate/blit, think you will need extra cycles).
The simplest test would be to fire up original asteroids, get to a hectic situation where there are quite a few objects on screen(a stress test if you will), pause, and just manually count lines and pick what you think is an average line length. Now make a test .hex on Uzebox where you: WaitVsync(1),Flush screen to black, then draw that many lines you counted, of what you felt was average line length, WaitVsync(1), repeat.
If the screen does not flicker then you're set I think the game logic might be somewhat heavy for that game(not sure but I bet it would take a lot of VBLANK time, and I also bet drawing needs most of VBLANK too), so I would first calculate game logic one tick(leaving the buffer un-updated from the last frame) then the next tick blank the buffer black and draw the scene using the updated object positions. This would give you the WHOLE vblank for drawing and the whole vblank for logic and still give you 30fps update rate. Course if they both fit in vblank time all the better to have 60fps. It would be one of the more impressive titles
The simplest test would be to fire up original asteroids, get to a hectic situation where there are quite a few objects on screen(a stress test if you will), pause, and just manually count lines and pick what you think is an average line length. Now make a test .hex on Uzebox where you: WaitVsync(1),Flush screen to black, then draw that many lines you counted, of what you felt was average line length, WaitVsync(1), repeat.
If the screen does not flicker then you're set I think the game logic might be somewhat heavy for that game(not sure but I bet it would take a lot of VBLANK time, and I also bet drawing needs most of VBLANK too), so I would first calculate game logic one tick(leaving the buffer un-updated from the last frame) then the next tick blank the buffer black and draw the scene using the updated object positions. This would give you the WHOLE vblank for drawing and the whole vblank for logic and still give you 30fps update rate. Course if they both fit in vblank time all the better to have 60fps. It would be one of the more impressive titles
Re: Asteroids
Hi Lee,
I assume the biggest challenge is the limited RAM in Videomode 6, because this mode uses 256 RAMTiles... the asteroids are only wire-frame models in this case. On the other hand this game will have a retro design like the original game from ATARI :
-Harty
I assume the biggest challenge is the limited RAM in Videomode 6, because this mode uses 256 RAMTiles... the asteroids are only wire-frame models in this case. On the other hand this game will have a retro design like the original game from ATARI :
-Harty
Life's too short to remove usb safely
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Re: Asteroids
Hi Harty,
Why do you say the RAM is limited in mode6? The tiles are 8x8 monochrome so that's 256x8=2048+(30x28)=2888 bytes. Since this mode doesn't use sprites structures, you're left with a "healthy" 1.2k of RAM. You would need a pretty fast line routine, so it would need to be in assembler for sure (as the point routine). I could contribute for this.
Why do you say the RAM is limited in mode6? The tiles are 8x8 monochrome so that's 256x8=2048+(30x28)=2888 bytes. Since this mode doesn't use sprites structures, you're left with a "healthy" 1.2k of RAM. You would need a pretty fast line routine, so it would need to be in assembler for sure (as the point routine). I could contribute for this.
Re: Asteroids
Hi Alec,uze6666 wrote:Hi Harty,
Why do you say the RAM is limited in mode6? The tiles are 8x8 monochrome so that's 256x8=2048+(30x28)=2888 bytes. Since this mode doesn't use sprites structures, you're left with a "healthy" 1.2k of RAM. You would need a pretty fast line routine, so it would need to be in assembler for sure (as the point routine). I could contribute for this.
yes, thats true, but don't forget we have a lot of objects in this case on the screen, because after the explosion of a big asteroid there are a lot of smaller asteroids. For every object we have to store several parameters (position, vectors for flight path, speed, rotation? ...). Thats why I'm afraid we have a problem with RAM.
About the line and setpixel routine: I saw in the code of the vector demo that this routines are written in C - a fast assembler routine for this is a very good idea. Also a getpixel routine is important for the collision detection...
-Harty
Life's too short to remove usb safely
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Re: Asteroids
Indeed RAM is always an issue but I never said it would be a perfect port either. You will have to sacrifice on the number of objects, their size and so on. Also I think a simpler bounding box detection may be required for speed reasons unless you use Lee's 30hz trick.
Re: Asteroids
Hi Harty,
As Alec suggested, you could simplify the bounding boxes of the asteroids into a smaller and square (or maybe rounder?) shape.
I use to play Comet Busters a LONG time ago for the old Win 3.1 and 95 platform. It used a relatively round bounding box and shape for every "asteroid". I'm just throwing it out as a suggestion.
However, in contrast, it uses sprites and images vice vector graphics.
-Mapes
As Alec suggested, you could simplify the bounding boxes of the asteroids into a smaller and square (or maybe rounder?) shape.
I use to play Comet Busters a LONG time ago for the old Win 3.1 and 95 platform. It used a relatively round bounding box and shape for every "asteroid". I'm just throwing it out as a suggestion.
However, in contrast, it uses sprites and images vice vector graphics.
-Mapes
Re: Asteroids
I tried writing an engine in mode 6 for Asteroids some time agao. I couldn't get it to even roatae one single triangle at decent speed. I'm not a very good coder and that could be the issue. I tried using floating point math to generate the locations of the corners and that may be the issue, but who knows. I can dig up the code somewhere I'm sure if you wanted it.
Re: Asteroids
The AVR has no floating point possessor. You gonna need fix-point math with trigonometric look-up tables, kind of like Old Allegro did.hpglow wrote:I tried using floating point math...
I think it's only the player sprite that rotates. If so then the look-up tables only have to be one byte large with maybe only 64 divisions of a revolution.
Re: Asteroids
I did a quick proof of concept. With no optimization at all, I could display at least a "big" asteroid, the ship and a bullet. All fits in the vsync interval, rendering is done using SetUserPostVsyncCallback(). So, with some assembly optimization I think a decent port of the game is feasible. I'll look at the optimization bit in the next few days.
- Attachments
-
- VectorDemo-src.zip
- (1.88 KiB) Downloaded 429 times
-
- VectorDemo.hex
- (23.06 KiB) Downloaded 438 times