Problems with pixels on GBA
Author
videoBuffer[x * SCREENWIDTH + y] = color;
Can anyone tell me how that works. I can get the program to run implementing this, but I don't understand how it does what it does, and apparently Jonathan Harbour says it has ...been passed down from one game programmer to another throughout history... and I assume a few people out there should know.
Also, for the R,G,B, 15-bit color function:
#DEFINE RGB(r,g,b) ((r)+(g<<5)+(b<<10))
How does that <<5 and <<10 stuff work? I just really want to understand so that I can apply these concepts in other applications.
videoBuffer[x * SCREENWIDTH + y] = color;
The buffer for the colours on the screen are being stored here in a linear buffer as in it is one continuous chunk of memory. By using this bit of math it allows you to access this array as if it were a 2 dimensional array. You just have to think about the math behind it a bit.
For example: say that the o is a dot on your screen,
xxxxxx
xxoxxx
xxxxxx
in memory it's actually stored as
xxxxxxxxoxxxxxxxxx
The buffer for the colours on the screen are being stored here in a linear buffer as in it is one continuous chunk of memory. By using this bit of math it allows you to access this array as if it were a 2 dimensional array. You just have to think about the math behind it a bit.
For example: say that the o is a dot on your screen,
xxxxxx
xxoxxx
xxxxxx
in memory it's actually stored as
xxxxxxxxoxxxxxxxxx
I'm going to give this a shot. Someone correct me if I'm wrong.
I don't know much about bit twiddling or color depths, but I think I can explain what is going on, in this case. Your macro takes in three separate values, one for red, one for blue, and one for green. You can provide a number from 0 to 255 for each color. If, for instance, you provide 255, 255, and 255, the color will be white. Sticking with white as an example, your macro converts your values into a single number. I.E. The color white would be:
Hex: FFFFFF
Dec: 16777215
Bin: 111111111111111
How is this achieved, you ask? To understand this, let's break down the problem a little further. If your macro parameters are (255, 255, 255), the values will look like this in binary:
Red: 11111
Green: 11111
Blue: 11111
To combine the values into a 15 bit number, you must shift the bits to the left and "concatenate" the values. For instance, if you take green and shift it to the left five digits, you get the following number, 1111100000. Similarly, if you shift blue ten digits to the left, you get the following number, 111110000000000. Now let's add them together:
000000000011111 //Red
000001111100000 //Green
111110000000000 //Blue
+----------------------
111111111111111 //White
You now have a single number, which represents your blended color. The only thing I'm unsure of is why the left most digits represent blue (maybe something to do with endianness?). I guess that's just how it works.
Did I clear your confusion?
EDIT: On a Gameboy Advance, huh? I make games for the Dreamcast, and from what understand, programming for them is similar.
I don't know much about bit twiddling or color depths, but I think I can explain what is going on, in this case. Your macro takes in three separate values, one for red, one for blue, and one for green. You can provide a number from 0 to 255 for each color. If, for instance, you provide 255, 255, and 255, the color will be white. Sticking with white as an example, your macro converts your values into a single number. I.E. The color white would be:
Hex: FFFFFF
Dec: 16777215
Bin: 111111111111111
How is this achieved, you ask? To understand this, let's break down the problem a little further. If your macro parameters are (255, 255, 255), the values will look like this in binary:
Red: 11111
Green: 11111
Blue: 11111
To combine the values into a 15 bit number, you must shift the bits to the left and "concatenate" the values. For instance, if you take green and shift it to the left five digits, you get the following number, 1111100000. Similarly, if you shift blue ten digits to the left, you get the following number, 111110000000000. Now let's add them together:
000000000011111 //Red
000001111100000 //Green
111110000000000 //Blue
+----------------------
111111111111111 //White
You now have a single number, which represents your blended color. The only thing I'm unsure of is why the left most digits represent blue (maybe something to do with endianness?). I guess that's just how it works.
Did I clear your confusion?
EDIT: On a Gameboy Advance, huh? I make games for the Dreamcast, and from what understand, programming for them is similar.
Author
Dreamcast? Have any looks for some good resources? I'm just trying to break into console development and cheap resources are hard to find.
I think I'm beginning to understand the RGB 15-bit thing, I'm sure I'll get more used to it as I practice with various other bit-depths. I still have to idea what's going on with the videoBuffer[x * SCREENWIDTH + y] = color; thing. Makes no since to me. Could someone give me some examples with inputs to the variables?
Thank you guys for helping though!
I think I'm beginning to understand the RGB 15-bit thing, I'm sure I'll get more used to it as I practice with various other bit-depths. I still have to idea what's going on with the videoBuffer[x * SCREENWIDTH + y] = color; thing. Makes no since to me. Could someone give me some examples with inputs to the variables?
Thank you guys for helping though!
a screen is 2d right? so you have x and y coords. but your memory is not 2d.. it is laid out linearly. the video memory is stored so that each row of pixels is put one after another each one with the same width as the screen. the y value is just what row you want and the x is how far in that row you want to go.
so it is very simple to get the correct memory location like this
location = x + y*WIDTH
if your curious about how that memory actually gets onto the screen. its that the video hardware in the gba periodically updates the screen. in that time it is wired to use a certian chunck of memory to represent the screen. that is the array you are using. make more sense now?
so it is very simple to get the correct memory location like this
location = x + y*WIDTH
if your curious about how that memory actually gets onto the screen. its that the video hardware in the gba periodically updates the screen. in that time it is wired to use a certian chunck of memory to represent the screen. that is the array you are using. make more sense now?
Think of it like this:
CPU sees the video memory like this:
address: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
value: z y x l k j i h g f e d c b a
But you see it like this:
0| 1| 2| 3| 4
z| y| x| l| k
--+--+--+--+--
5| 6| 7| 8| 9
j| i| h| g| f
--+--+--+--+--
10|11|12|13|14
e| d| c| b| a
The conversion from your representation of video memory to the CPU's representation is:
address = x + y * w
Where w is the number of columns in the array (in this case, 5)
For example:
To access (3,2) in the array, plug it in the equation:
address = 3 + 2 * 5
= 3 + 10
= 13 ('b')
To access (0,1) in the array...:
address = 0 + 1 * 5
= 5 ('j')
Does this help?
EDIT:
It changing the pixel's color at coordinates (x,y). Aka, it's drawing a pixel on the screen.
(It probably should be videoBuffer[y * SCREENWIDTH + x], unless the video is transposed...)
CPU sees the video memory like this:
address: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
value: z y x l k j i h g f e d c b a
But you see it like this:
0| 1| 2| 3| 4
z| y| x| l| k
--+--+--+--+--
5| 6| 7| 8| 9
j| i| h| g| f
--+--+--+--+--
10|11|12|13|14
e| d| c| b| a
The conversion from your representation of video memory to the CPU's representation is:
address = x + y * w
Where w is the number of columns in the array (in this case, 5)
For example:
To access (3,2) in the array, plug it in the equation:
address = 3 + 2 * 5
= 3 + 10
= 13 ('b')
To access (0,1) in the array...:
address = 0 + 1 * 5
= 5 ('j')
Does this help?
EDIT:
Quote:Original post by pbjgame
I still have to idea what's going on with the videoBuffer[x * SCREENWIDTH + y] = color; thing.
It changing the pixel's color at coordinates (x,y). Aka, it's drawing a pixel on the screen.
(It probably should be videoBuffer[y * SCREENWIDTH + x], unless the video is transposed...)
Quote:Original post by pbjgame
Dreamcast? Have any looks for some good resources? I'm just trying to break into console development and cheap resources are hard to find.
Thank you guys for helping though!
Sure do:
An incredible community dedicated to DC homebrew
<http://dcemulation.org/?title=Welcome_to_DCEmulation!
Instructions to set up your development environment on Linux
http://www.dreamcast-scene.com/index.php/Main/LinuxToolchain
Instructions to burn your elf binaries to a CD-R
http://curmudgeongamer.com/article.php?story=20040105232756356
Programs needed to burn your binaries*
http://mc.pp.se/dc/files/makeip.tar.gz
http://mc.pp.se/dc/files/scramble.c
Repository of dcload (If you have a broadband adapter)
https://cadcdev.svn.sourceforge.net/svnroot/cadcdev/dcload/dcload-serial
Windows tools (Although I don't use them, and I want to start)
http://dcemulation.org/phpBB/viewtopic.php?f=29&t=96802
http://dchelp.dcemulation.org/
Those are the important resources, but I'd be willing to help if you need it. Hell, I've been thinking about compiling instructions for beginners who need help getting everything running and perhaps drawing something to the screen. I modified one of the examples, that I wouldn't mind giving you, if you have trouble drawing something to the screen. The only thing you have to keep in mind is that the size of the images has to be a power of two. It took me a long time to figure that one out. Overall, however, programming for the Dreamcast has been an easy transition, and I would argue that after the initial setup, it is no more difficult than programming for the PC, although I haven't ventured into 3D.
I'd just like to take a second and list the reasons why I enjoy programming for the Dreamcast, maybe I'll influence someone in a positive way. Here's why I think it's so great:
- Legal, as far as I know
- Cheap, if you go the route of blank CD-Rs
- Sharp community
- Quality homebrew libraries
- More satisfying that PC development, for me
- Relatively simple (And if you're familiar with SDL, there is a port, although I don't use it)
The only major drawback is that you greatly limit your audience. To my surprise, many of my friends don't own a Dreamcast, and non-gamers usually haven't heard of it. But the people who I show my game to seem to be more impressed that it is on a console. And by the way, feel free to download the source code to my game, Poncast, but unfortunately I lost the most recent version. It is still fun and playable, however, so if you have a chance, check it out here:
http://anothrguitarist.googlepages.com/Pongcast.zip
*NOTE: The files at the aforementioned link work, but the instructions are outdated -- beware.
[Edited by - anothrguitarist on August 14, 2008 5:37:09 AM]
Author
Wow, makes so much more sense now, thanks guys!
And I'll definitely check out that Dreamcast programming, one of the few consoles I havn't owned, and I really want to go pick one up.
And I'll definitely check out that Dreamcast programming, one of the few consoles I havn't owned, and I really want to go pick one up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
