Neon GBA Lighting Engine

[YourNerdyJoe]

As of 3/26 I decided to do the One Game a Month challenge. March's theme is Neon hence the neon-ish colors.

How it works:
This uses 2 of the gba's bg layers. One is used for the lighting effects and the other contains the tiles in the background. The two are then merged with the gba's hardware color blending.

The lights cast rays over the tiles and sets the tile's brightness for that color light depending on how far away the tile is from the light source. So if a tile is close to a green light and far from a pink light, that tile's color brightness (as I'm dubbing it) for green might be 3 (max 4) and its color brightness for pink might be 1.

All of the different possible combinations of colors and brightness for the lights are calculated using a separate program I wrote. It spits out a total of 253 colors into a nice little c array which is compiled with the game. If you notice anything weird with the blending of the white light with the other lights, that is because I ran out colors as I thought I would (since the gba can only hold 256 colors in the bg palette). There was only enough space to mix one shade of white in with all of the other colors so I had to code in a little something extra so wouldn't be that noticeable.

In theory this could have been done with a light on each layer and then using the gba's color blending so I wouldn't use up palette space blending colors. However, in practice, this would severely limit the capabilities of the engine since there are only 4 bg layers. In addition, if only 2 layers are used like they are now, I could use video mode 2 which would allow me to do crazy rotation and shiz on those 2 layers.

Today I should be able to implement light mapping so I'm not casting 64-128 rays each frame for huge lights that aren't moving.

If anything is unclear, confusing, or you just want me to explain more about it please feel free ask

TLDR: THE COOOOLLLORS MAN.

[Falco Girgis]

That... is fucking awesome, dude. I am impressed, and I love the concept.

[ph0sph0ruz]

That is pretty cool. Forgive my ignorance but how are you coding for the GBA? Is there an API or something and an emulator? Thanks!

[YourNerdyJoe]

That... is fucking awesome, dude. I am impressed, and I love the concept.

Thanks man! Means a lot coming from you

That is pretty cool. Forgive my ignorance but how are you coding for the GBA? Is there an API or something and an emulator? Thanks!

Didn't mean for this answer to get so long. It's simpler than it looks (I think/hope)
I'm using devkitpro which contains the compiler and libraries for devvin' on the gba. I started with devkitadv which is similar but it doesn't have the libraries and it's pretty outdated now. Since I started without libgba I got used to not using it. So I use a .h file with #defines for each register (REG_DISPCNT,REG_BLDMOD,etc). Anything else I need I normally create my own header file for based on info from tonc or gbatek.
As far as emulators go my personal favorite is VisualBoyAdvance. It includes some useful tools like a memory viewer, tile viewer, etc that come in handy when devin'.
I also have a usb flash cart for the gba but I haven't used it in a while b/c I can't get the software to work with windows 7 and up and I don't feel like busting out the old xp desktop after every build. Hope to build a uart cable before the summer so I can upload games from my pc directly to the gba.

The GBA is what got me into C back 3-4 years ago, glad I'm finally getting around to something worth releasing.

[ph0sph0ruz]

Thanks Dude! I didn't even know all this stuff was out there until recently. I'll have to check some of these kits out.

[YourNerdyJoe]

Thanks Dude! I didn't even know all this stuff was out there until recently. I'll have to check some of these kits out.

No problem man.

Just finished light mapping and static lights earlier today.
The only difference between the 2 is that the light map is an array of pre-computed values and the static lights are computed when the game loads. Both run just as fast.
I probably won't make another video until at least next weekend when I have a few more things to show off.

[dandymcgee]

This is really cool! Neat idea, thanks for the video / explanation.

[eatcomics]

Thanks Dude! I didn't even know all this stuff was out there until recently. I'll have to check some of these kits out.

It's pretty cool, a year or two ago I bought a flashcart and played around with the API, I got backgrounds loading and some sprites, but after that I got busy. It's a ton of fun and a good way to get a feel for some lower level stuff

On the topic of your demo, that is fucking cool. How hard is it on the poor little machine? Looks pretty involved processing wise.

[YourNerdyJoe]

How hard is it on the poor little machine? Looks pretty involved processing wise.

After about 4 lights it does begin to lag a little but there is still room for more optimization. The static lights, however, are hella fast since they only need to be computed once.

I should have another video up tomorrow which will show off some new features and something that actually resembles a game.
Don't get too excited because the video will be short for reasons that will be explained after I upload.
It comes down to stupidity

[YourNerdyJoe]

New video up now!

Added support for lights to fade over time which is used to create samus' beam.
This is done by giving each tile a "fade" brightness value (for lack of a better name) which decreases each frame. It's then added to the initial brightness that is set by the static lights (like the 2 white ones) and light maps.

The reason the video is so short is beacuse I used an entity system I wrote about half a year ago just to see if I could implement it in C. Spent little more than a week end one it and did very little testing. Being the genius that I am I thought "well I wrote this in c so I'll use that old engine I wrote in c that has very poor memory management." The only smart thing I did was keep the code separate.
If enough people want to see the epic fail I'll post the full video. Random memory addresses are being writen to so some freaky TMTRAINER level things start popping up all over.

In the (maybe near) future I plan redoing this with lua wrapper and release it for people to play around with.
The bugging entity system WILL be removed by then. (Just to clarify, I have made a much better entity system than this in c++ and this one was made as a quick challenge to see if I could get it to run in c)

[dandymcgee]

Holy crap, that is freaking awesome! Really cool effects.

If enough people want to see the epic fail I'll post the full video.

You know we do..

[YourNerdyJoe]

Holy crap, that is freaking awesome! Really cool effects.

If enough people want to see the epic fail I'll post the full video.

You know we do..

WEEEELLLLLLLLL, it looks you guys are in for a treat

[YourNerdyJoe]

Here it is you sadistic bastards!

I understand how the graphical glitches occur but I am very surprised that the friction flag is set in the beam's PhysicsComponent.

I have started working on the lua wrappers for this. Plan on releasing the rom when I'm done (which won't be for a while) so you guys will be able to write your own scripts for it.

[dandymcgee]

Lol, it's always funny when you mess up something minor and everything goes to hell. I remember blowing on NES carts trying to get the palette to stop looking like the color test channel.

Who remembers this?

[bbguimaraes]

Surely that's not a bug. It's hardcore mode, where monsters have powerful illusions that make them invisible, twist your beams and displace the background. It also happens to be the only mode