what i dont have a concept of is Game algorithms, eg dealing with gravity and velocity ...
You know how to move a sprite, correct? You add an increment to the current position to get a new position...
So, what if your increment is a variable (as opposed to a constant)? In response to the joystick presses, you update the increment variable, which then gets added to the sprite position. That's how velocity and gravity are usually done (though gravity decrements the increment variable, so you rise less and less)
The other option (which allows for fine tweaking) is to use tables. On this step, add this... works surprisingly well, and is easy to code.
Both of these methods can be quite convincing, especially if you use fixed-point values
or understanding collisions
Bounding box is simple and quick, especially for squarish sprites. Pixel collision is expensive, but if you understand boolean operations, you can test a whole row of pixels as easily as testing each individual one. The downside is setting up the correct masks.
An interesting alternative to bounding boxes is to use distance measurements. No, you don't -have- to sacrifice cycles to square things either. Comparison of the X and Y differences to a known 'hit distance' can be just as effective.
The real question, though, is how you set the origin of your sprites. From experience, using center-based coordinates works better in many cases, and leads to simpler algorithms. If needed , you can always convert to a corner based origin with a simple add/subtract.
Right now i understand and have done the basics with Yaroze ( PSX Dev in C ),
Wow. There's one I haven't heard in a while. I played with that for a couple of months, but the way the libraries and such were set up was pretty limiting, iirc. I eventually 'upgraded' to the hacked libraries. I still don't understand the decision behind those wierd fixed point numbers....
Arkhan Himself can code well in 6502 but has the impression it's for brain damaged coders....
Not really. He's from a generation that started with C, so that's more natural to him. He's used to some things being taken care of for him (Adding an int takes 2 adds? And you have to clear the carry first? Why?) What he does have a problem with is the fact that it's more difficult to debug assembler. You usually have to step through it with a debugger, instead of printing values to see what went wrong. That just takes too much time for him
[ Just for reference: I started with Basic, then moved to 6809 asembler. When C came out, I learned it - and liked it enough that it's my preference of languages. A full C compiler makes state machines as easy as doing them in assembler. Unfortunately HuC is not a full C compiler. I miss int (*(move[]))()....or whatever the exact syntax is. I haven't done it in a while
]
Topic: Basic 2d game dev resources (Read 708 times)
