Vector Demo

Use this forum to share and discuss Uzebox games and demos.
Post Reply
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Vector Demo

Post by uze6666 »

Image
As promised recently, I'm releasing the work I was doing on a "vector" mode. It's more of a monochrome bitmapped mode using 255 ramtiles. The foreground and background color can be independently set per scanline. I guess some simple vector games could be done with it (or nice 3D demos :mrgreen: ). Runs fine on the emulator too.

It's only a work-in-progress and not optimized at all, but you'll get the idea. If anyone want to take on this, be my guest. :)

Cheers,

Uze

edit: The sources are in svn: http://code.google.com/p/uzebox/source/ ... VectorDemo
Attachments
VectorDemo.hex
(20.66 KiB) Downloaded 338 times
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Vector Demo

Post by paul »

Cool demo!

So it goes pixel -> vector -> polygon -> mesh -> ... -> dynamic shadows. We're getting there ;)

Always fun to see what you guys can squeeze out of this little chip. I definitely would love to see Hovertank 3D at some point down the road.
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Vector Demo

Post by pragma »

That's fantastic Uze. Looks like we can expect a Battlezone clone at some point, eh?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Vector Demo

Post by uze6666 »

Or an Asteroids clone. It's gonna be nice challenge to optimize the line & pixel routines since they are now in C and quite slow. Hmmm, just realized that the demo was compiled with -O0 ...

Uze
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Vector Demo

Post by pragma »

uze6666 wrote:Or an Asteroids clone. It's gonna be nice challenge to optimize the line & pixel routines since they are now in C and quite slow. Hmmm, just realized that the demo was compiled with -O0 ...

Uze
The mode 6 rasterizer looks as simple and optimized as you can get. It's amazing how simple this gets when there's no sprite support. ;)

It looks like you can speed up SetPixel quite a bit in assembler. The line function (Bressenham style - good move BTW) looks like it maintains just few enough temporaries to run entirely in registers - *exactly* 30 bytes worth including the parameters by my count. With some judicious use of push/pop and elimination of un-needed temporaries, I think you can expect to speed that up dramatically. For instance, you can throw away dxabs or dyabs depending on which branch you follow, which frees up another two registers for each loop.

I see that you're using ramtiles, but your allocation function in SetPixel() confuses me a bit. Are the ramtiles sparsely allocated, or is every single pixel on the screen represented in the ramtile set?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Vector Demo

Post by uze6666 »

It looks like you can speed up SetPixel quite a bit in assembler. The line function (Bressenham style - good move BTW) looks like it maintains just few enough temporaries to run entirely in registers - *exactly* 30 bytes worth including the parameters by my count. With some judicious use of push/pop and elimination of un-needed temporaries, I think you can expect to speed that up dramatically. For instance, you can throw away dxabs or dyabs depending on which branch you follow, which frees up another two registers for each loop.
Yep, It's definitively as assembler job. The c code is just for testing (much easier to debug in AVRStudio).
I see that you're using ramtiles, but your allocation function in SetPixel() confuses me a bit. Are the ramtiles sparsely allocated, or is every single pixel on the screen represented in the ramtile set?
Here's the way it work. Each time a pixel must be plotted, the VRAM address of the tile in which it would fall is computed. Now if the tile # in VRAM at that address is zero then we need to allocate a new ramtile and plot the pixel in it. The VRAM is then adjusted to point to that ramtile. Otherwise the pixel is plotted to the existing ramtile. When allocating new ramtiles if we already have already 255 ramtiles allocated, the pixel is ignored.

Uze
br4nd0n
Posts: 1
Joined: Fri May 29, 2009 7:33 am

Re: Vector Demo

Post by br4nd0n »

Very cool vector demo! I'm definitely looking forward to doing some line-drawing 3D stuff...a-la Vib Ribbon, if you know the game :-D
User avatar
TonyD
Posts: 134
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK
Contact:

Re: Vector Demo

Post by TonyD »

Battlezone, Asteroids pah ;) I say Elite, the best vector graphics game IMHO of course :D

Does this mean we should fire up our Vectrex's and start ripping ideas?

If this is video mode 6, whats in store for video mode 5?
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Vector Demo

Post by pragma »

TonyD wrote:Battlezone, Asteroids pah ;) I say Elite, the best vector graphics game IMHO of course :D

Does this mean we should fire up our Vectrex's and start ripping ideas?

If this is video mode 6, whats in store for video mode 5?
It's a work in progress - the 'demo' for my Castlevania game shows it off. So far I have something that takes mode2's screen section support, and allows two different horizontal resolutions per section; one like mode2, the other like mode3. At the same time, each section also supports independent manipulation of the DDRC register, which allows for independent fading of each section. One tile's worth of x/y fine scrolling is also supported for each section.

I'm presently working on a lot of other stuff, but I hope to look at hybridizing the sprite rendering with ramtile support before I consider it 'done'. Also, the working version I have is built against an older kernel so I have a long way to go.
Post Reply