Coder's Hang-out

[pkt-zer0]

Nah, I dislike counting clock cycles and comparing the speeds of register access. Also, the concepts of AI and assembler don't really like go well together. I also found it a bit troublesome (back when I tried my hand at VGA under DOS) that if you want to do something that's not supported on the hardware level, you'll have to optimize it real hard. Scrolling was a pain, I imagine I probably wouldn't have been able to get some unfilled polygons to display in 3D there at decent speeds. And the last thing I'd want to do is optimize mathemathical routines in assembler.
To each his own, I guess.

I hope your stuff will work in VBAdvance.

[crusher]

Scrolling isn't at all that hard. I coded my own engine for GBA. It's pretty slow, unoptimized and kinda buggy but it works! It's a pretty simple concept where you just load parts of the map, read from an array, into the area of the "play field" that is outside the screen (don't remember the name of this area).

I don't want to touch assembly and thankfully, you really don't. Except perhaps when you need create some really good interrupt routines. But I haven't got that far yet.

And yeah I probably will continue working with GBA. It's fun. Oh and I got a question. I tried to search for an answer but couldn't find anything. So here goes, what's the difference between Vblank and Vdraw?

[pkt-zer0]

I know what scrolling is. I meant scrolling only part of the screen, like a floating menu. First I tried copying the memory fields line by line, replacing the empty parts with the background. I got better results with that by redrawing the whole screen into an array and blitting the whole stuff to the screen. But still, that felt like a bit of overkill.

Well, if you'll be wanting to code graphics on consoles, you will be touching assembly, as you probably won't be able to optimize drawing routines any other way.

I don't know a thing about GBA-specific routines, so what on Earth would be Vblank and Vdraw at all? I only know about V-Sync, and I don't know how applicable that is for GBA.

[crusher]

Well that ain't a problem when it comes to the GBA. There are two different window layers so yeah.

Coding the graphics? That depends on the hardware I guess. Yet again, on the GBA, it isn't necessary. The drawing is as fast as it gets when you have access to 3 different DMA channels.

I believe Vblank and V-Sync is one and the same thing. However, I'm not sure of vdraw...

[pkt-zer0]

Meh, bastards.

I was assuming that because I know some team here is looking for a C coder, to make a DS game, and they have the graphics part coded in assembler.

I just read up on it, it really seems that Vblank is just the same as vertical synchronization. You update graphics right after it gets drawn to the screen, not before it, therefore there's no tearing. Whoo. Vdraw might be just a method for waiting for the Vblank interrupt.

[crusher]

Well I dunno about the official development kit etc, but it seems that most amateaur developers use C. But your code will be much cleaner and better if you code in assembly. But that isn't fun, now is it?

Yup. In the code I'm currently using, which I partly stole from a tutorial, the Vdraw is called after updating the graphics. So I'm really not sure about that one.

[pkt-zer0]

Cleaner? No. Just check out Cassini. Faster? Hell yes. In the case of consoles, there's not even the compromise of lack of portability.

http://64.233.183.104/search?q=cache...ient=firefox-a
Found this in Google's cache, that should clear up things.

[crusher]

Ok ok, cleaner was just poor thinking from my side. I know that assembly looks like a damn mess. Thanks god for high-level programming languages. Make no mistake though, I've got some experience with assembly. We even programmed a microchip once in school. Don't remember the name of the chip anymore though.

http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm
That document is my number one reference material.

Anyway, so after Vdraw, you should do stuff that doesn't affect the display? I see, I see. Thanks for pointing that out.

[Jedi_Amara]

Ok ok, cleaner was just poor thinking from my side. I know that assembly looks like a damn mess. Thanks god for high-level programming languages. Make no mistake though, I've got some experience with assembly. We even programmed a microchip once in school. Don't remember the name of the chip anymore though.

http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm
That document is my number one reference material.

Anyway, so after Vdraw, you should do stuff that doesn't affect the display? I see, I see. Thanks for pointing that out.

We did that last year in first year. It was weird... I couldn't figure it out from the notes we got beforehand, but it was pretty easy in the lab.

[crusher]

Well, I decided to drop the IK arm porting and am not working on some basic GBA stuff again. Trying to optimize and actually make something this time. Here's what I've done so far.

Obviously, it's a GBA ROM.

[pkt-zer0]

Not bad. You should at least implement some jumping soon. And the controls are a bit odd right now. What I mean is that 'left' simply overrides right. It should be like that whatever button was pressed last overrides the previous, but if a direction remains pressed after releasing the other one, the guy goes that way.
What kind of collision detection are you using, by the way?

[crusher]

Well I don't think the controls are that weird. I just checked with Mega Man Zero 4 and the controls responds in the exact same way. And you know, when playing on the GBA, you can't push left and right at the same time. And yeah jumping is coming.

As for the collision detection, I'm not familiar with any common methods. But my method is related to the the map structure of the level. I've built a meta map system (16x16 tiles) and by checking whether or not a position in the map array equel to the current position of the player is 0, the player can move or not. Zero means that it's an empty area and you can walk through it. Easy stuff.

[pkt-zer0]

Silly me. Never thought of the stuff running on an actual GBA... well, that explains it.

Figured as much, I did the same. For enemies/bullets, I simply used a bounding box. Things like circle/semicircle/ellipse could possibly be useful, but I didn't bother.

[crusher]

I haven't come as far as working on enemies. I still want the actual player to work as good as possible before I do that.

Just now I fixed the animation system. It was pretty complex but now I just change animation every 16th frame. Works great. Gonna see if I can add jumping. I know how it should be done so I think I can get it working pretty quickly.

[crusher]

Oh and sorry for the double post, but just some small questions. Would you like to explain this operator to me:

"->"

From what I gathered, it's used in functions to set a a variable inside a struct to a value. Because you can't use a "." [dot] for some reason... am i rite?

so in other words..

sprites[0].x = 1111;

and

sprites->x = 1111;

are one and the same thing. Right or wrong? Please enlighten me.