Programming Sprites

[music_man05]

Hey folks,

I am just starting a project and I am gathering information in order to plan things out ahead of time (imagine that)

The project is this....

use a Xilinx FPGA board...use VHDL to design a processor on it and make your own ISA to work on it.
Then, write a program(in C) that, when compiled and assembled, will work on your processor.

My job for this project is to do, you guessed it, The C program.

My program I decided would be a guitar hero style game using keyboard keys, and a few extra features(not important for this post, but you get a picture of whats up)

I am going to tackle the graphics of the game by using sprites, since our processor doesn't have a very large memory base and our VGA is not a very large resolution.

I have never worked with graphics in C programming before, nor have I worked with sprites.
Can people who have, post some information, whether it be links, source code, or advice on how to go about doing this. Any help is appreciated...

Thanks,

Cody

[Salem]

I'm guessing there won't be an operating system or graphics library running on this processor when you're done.

Will you be compiling the code on your PC, then copying the executable files to your board (in some way)?

[music_man05]

Basically, the system works this way.

We create our own processor(in our case we are basing our processor on a MIPS like architecture) and we are following the Instructions for the assembly code. The C program I write will compile to assembly and then we will assembly it into binary.

We are making our own VGA controller that is like an 80X60 grid of 10X10 squares, inside each of these squares in our images(sprites).

Again I am very new to the idea of sprites, but that is basically it. I can go deeper in the explanation if anyone desires, but I just need to know a good starting point and research information as to how to go about doing this efficiently.

thank you.

[MK27]

AFAIK, traditionally a sprite is just a 2D arrangement of pixels that can be moved in relation to an x/y (or xyz) coordinate system.

From the sounds of things, you are not going to be able to use any graphics libs, so you just need to have an understanding of how your hardware "framebuffer" (in this case, "our own VGA controller that is [800x600]") works with data.

Nb, I don't see the point in a "80X60 grid of 10X10 squares". If a sprite is 10px by 10 px, you probably don't want it to jump from one such square from to the next -- you want it to move one pixel at a time. So such a grid will be useless.

A starting point would be to devise something that refreshed the entire 800x600 display at a given interval, say 20 times per second. Then you just keep track of your sprite x,y positions (eg, based on the top left corner). If you have a 10x10 sprite and you want to move it from 0,0 to 790,0 over ~10 seconds, then you add 4 to the x every frame (4*20*9.85 = 788). 9.85 seconds @ 20fps is 197 frames.

[VirtualAce]

80X60 grid of 10X10 squares

That sounds more like text mode to me.
What you need is an 800x600 array of pixels or at the very least 640x480. Sprites are simple to program but the first thing you will need is a function to write pixels to the screen and/or blit offscreen data to the frame buffer. Your sprites routines use the image routines to write data to the offscreen buffer and the blit code then blits the entire final screen image to the frame buffer.

It is easy to write blitting routines for sprites but they are not very robust. It would be better to write a routine that could scan convert a quad regardless of it's 2D orientation. It's not as hard as it sounds and it makes it a snap to rotate sprites. But if you just want blitting that code is really simple to write provided you know the pitch of your buffer and how your buffer is laid out. Does 1 byte represent 1 pixel or are you using color planes, etc,. etc.?

[music_man05]

As far as I know(since I am not working on the VGA controller) we have a limited amount of memory, so the resolution will be deluted a bit, but from the sounds of it, the vga will refresh its data continuously checking the memory slots for updates to the coresponding locations.

Now, I believe it is possible to make it so that the movement of the sprites isn't has choppy has a jump of 10 pixels per "update" to the screen, so that is not my concern.

I guess if i understand you correctly(and thanks for helpin') I am basically just doing work to the memory locations and changing the data according to the vga refreshing?

the only way to test the code I have written is to use it on a simulator until the hardware is implemented. I am hoping it can simulate my sprites actually working.