Public Group

# Problems with pixels on GBA

This topic is 3601 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

##### Share on other sites
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

##### Share on other sites
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.

EDIT: On a Gameboy Advance, huh? I make games for the Dreamcast, and from what understand, programming for them is similar.

##### Share on other sites
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!

##### Share on other sites
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?

##### Share on other sites
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:
Quote:
 Original post by pbjgameI 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...)

##### Share on other sites
Quote:
 Original post by pbjgameDreamcast? 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

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:

*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]

##### Share on other sites
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.

1. 1
Rutin
19
2. 2
3. 3
4. 4
5. 5
frob
12

• 15
• 13
• 9
• 12
• 10
• ### Forum Statistics

• Total Topics
631442
• Total Posts
3000104
×