When zoomed at level 2 for example, each pixel on the TV is equal to a 4 x 4 square on the gamepad. So instead of drawing the whole 4 x 4 square, half is the picture on the TV, the other half is black, to speed up the drawing on the gamepad. The effect of this makes the zoomed in image have scanlines. This has no effect on what the image looks like on the TV, but speeds up the rendering on the gamepad. If I didn't lay down a black background first, I would have to render the complete pixel as a 4 x 4 square on the gamepad, which is just a waste of CPU cycles. It has the same effect as looking at an old TV with scanlines, and only makes the image look darker. I never really had a problem with it, but if it bothers you too much, you could extend the loop in the copyPixels routine and recompile it, but you will get major graphics tearing when moving around the image. As it is, it tears enough, but not as bad as if you extended the loop.
I don't think I compiled for 5.4, and someone correct me if I am wrong, but I believe either the 5.3.2 or the 5.5 bin file should work on 5.4. I don't have 5.4 firmware, so I am not exactly sure of the differences. You could always change the Makefile to include 5.4 if it is different.
Actually, I wouldn't practice what I put in my code, I put some unsafe code in it, and most of that I only did because of the limited size of the .bin file. Now that we can make elf files though, I can maybe code "correctly" now.Sweet new 2.0 release!
And I see you've released the source code! I could learn a thing or two from this, I bet!
Thanks a lot!
I included all compiled version bins in the bin folder with the source code.
heh, what do you mean by this? The only unsafe code I know of is code which messes with the actual system itself.
Look at how I did the colors. If I tried to make a color struct array larger than 8 items, the compiler told me I had to have a memcpy function, so I created another color array with the last two colors and put them directly after the first color struct array in my global struct. At the start of the program I fill the first array and then immediately fill the second one. Then I can call the second array by using the 9th and 10th (actually 8th and 9thheh, what do you mean by this? The only unsafe code I know of is code which messes with the actual system itself.
) item of the first array. I've always been told that doing things that way is unsafe, because you don't know where it will actually pull the value from, but from experience, it will always work this way, because the memory addresses in a struct are one after the other. That's why I say it is unsafe. I am asking for a value from an address that I am not sure actually contains the value I need. But hey, if it works, it works. If it wouldn't have worked for this program, then I would have re-wrote it "correctly".
I will be compiling it in elf, right after I finish the elf version of Asturoids. I released the source with this though, so anyone could compile it for an elf if they wanted.
That's great to hear and since you're doing Asturoids as well (and maybe even more homebrew?) you should put all recent builds into your signature.
Thanks. I've already converted Ast-U-Roids to be compatible with the Homebrew Launcher and I am currently working on adding sound to it now that I can. That is just the beginning, because I have a lot of things planned, just not sure how long it will all take though. I will eventually get this one converted for the Homebrew Launcher too, but since the source code was released with it, I haven't made it a top priority at the moment. BTW, if anyone wants to convert it, feel free, just please credit me for the original source code.
K3Nv2
DinohScene
Veho
@
Xdqwerty:
