better sprite tutorial on wiki.superfamicom.org

I think there should be a better sprite tutorial on wiki.superfamicom.org, concerning how important sprites are for an SNES game. I've witnessed a lot of people getting stuck with not knowing how to get a sprite onscreen. There is a code example for how to clear the oam, but nothing on how to display a sprite.

Here are some pointers on what I feel a "draw sprite" example code should incorporate.

-16-bit x and y parameters
-bounds checking
-a seperate code for processing the 32 bytes of hioam

psycopathicteen,

With what you know and have done already, maybe it's time for you to write this tutorial?

As for how I got my first real job, showing in my portfolio some tutorials I wrote and (graphing calculator) games I posted on the web held a lot of weight.
It shows you can think clearly about a topic, and better than that, shows that you can demonstrate your knowledge to other people who then can apply it themselves.

http://wiki.superfamicom.org/snes/show/ ... ay+sprites

Here is a new sprite tutorial I wrote. Any constructive criticism?

what assembler will assemble the code posted?
where are all the symbols defined?

A section showing "During vblank period, DMA the OAM buffer, into OAM." is not present. how is this done?

what startup code is needed in order to get the SNES into a condition to run the code you posted?

In other words, this ought to be an actual example where these subroutines could be included in a full source file (minimal as needed, of course, without all your secrets) with data for an actual sprite character (whatever it may be) and a table set up in RAM and all the necessary symbols defined as constants or RAM memory locations. Then show a screenshot of the result of running the program.

I mean, I get what the code does, but it isn't runnable in its current form.


I know this is kind of ancient dinosaur stuff, but if you can catch it at the beginning of the video, that's all the code that's needed to display moving sprites on the TI-99/4a...
https://www.youtube.com/watch?v=SPwRYXYO7yk

The X and Y velocity in this example is just randomly set, along with a random color. A hardcoded VBLANK routine in the console ROM just adds the X and Y fractional velocity to the position stored in a table, then sends the table into the sprite memory of the chip through a port that auto-increments its internal address. No such thing as DMA though.

It's a short, simple, stupid, yet interesting way to show how to display sprites on the system using BASIC. The TMS9918 was basically the first video chip to display sprites in a way which lasted up through the SNES era.

Maybe you can provide a simple example where the main routine is just a few lines of calls (jsr this, jsr that), and the dirty work of setting things up is handled by the subroutines, then just loop forever?

If someone ported this demo to the Super NES, would that be enough?

My old SNES docs contained a demo that came with such source code. I did not do a good job commenting it, and as some have pointed out the resulting ROM was not padded to proper alignment/mask ROM size (don't want to get into this, those were different days and nobody wants a ~32KByte demo taking up 512KBytes on a floppy disk where 480KBytes are zeros or 0xff), but it does get the user started, including proper power-on initialisation. I did not, however, do jack squat with OBJ.

My response is just with regards to the link you used an as an example, because the things there (barring the animation) are mostly what I already did.

Really what people want is lots and lots and lots of hand-holding and step-by-step documentation written by someone who isn't going to inundate them with shitloads of low-level technical details -- not source code. The number of people who can sit down and learn a platform simply by reading existing source are fewer than those who want to work on a platform and don't know the source. This is why people latch on to wonky things like "NESBASIC" and other whatnots -- people seem to think developing for a console is equivalent to writing a grocery list and magically leprechauns make it all happen, or something.

You can't just fill source code with craploads of comments either -- too many comments turn a person off to the point where they won't read them. I think everyone to some degree has encountered this. It's particularly annoying when the comments don't say anything useful or reiterate the same thing just phrased differently (please don't pull the race card on me or anything, but I find the latter happens a lot in code written by Indians). You kind of have to have a sane way of documenting something "along side" the source, and there really (even today) isn't a good way/program/environment/etc. to do that.

For me there is some amusement in seeing someone wanting a sprite tutorial for two reasons: 1) because I never did anything with OBJ myself, and 2) because in the early 90s I sat for hours (across multiple days) banging away on code trying to figure out how the SNES's graphics worked (assemble, wait, copy file to floppy, wait, put floppy in copier, power-cycle, load demo from floppy, see results. Didn't work, try again), specifically mode 0. I still to this day remember the excitement I got when I actually got something on-screen, and the follow-up excitement a day or so later when I got multi-coloured text on-screen. There was no tutorial, there was no documentation, there were no examples, there was just reverse engineering and trial and error.

But hey man, Snoop Dogg says everyone should code...

Source code tutorials I think are really only useful when the reader is already knowledgeable about asm and system writes. It took me five minutes to figure out HDMA from a demo source, but that's because I know enough about programming the NES and GBA the SNES isn't much of a learning curve.