Returning address of pixel...

Okay, this is my first graphic-based game. It's also my
first real program using pointers and FILE I/O functions.
So, if my question doesn't make any sense--don't make fun
of me. Please.

By the way, a lot of the stuff I'm trying to do won't even
be used in my game--I just keep trying various things so I
can become more 'comfortable' with these concepts.

I'm trying to make a 13h game. Right now, I'm
trying to make a function that returns the address of a
plotted-pixel. Here's my pixel-plotting function:

Code:

---

//Global
typedef unsigned char BYTE;
typedef unsigned short WORD;

BYTE *g_vgamemory = 0xA0000;

int PixelPlot(char color, int x, int y)
{
  WORD offset        = ( (y *320 + x) );
  g_vgamemory[offset] = color;
 
  return 0;
}

---

Anyway, I want to make a function that returns the address
of a pixel (as I've said). But I don't know where to start.
What return-type do I give the function? I mean, g_vgamemory
is a BYTE, but the offset is a WORD.

Would it be this...?

Code:

---

BYTE *get_pixel_add(int x, int y)
{
  WORD offset        = ( ((y *320 + x) );
  return &g_vgamemory[offset];
}

---

Or this...?

Code:

---

WORD *get_pixel_add(int x, int y)
{
  WORD offset        = ( (y *320 + x) );
  return &g_vgamemory[offset];
}

---

...g_vgamemory is of type BYTE. But I don't see how that
function could work since it only holds a value of 0-255,
and there's 64,000 possible places the pixel could be (??)

If I'm suppose to use the WORD function, would I need to
typecast g_vgamemory as a WORD? Please help. (Please explain
your answer too. I want to know how to do it, but more
importantly, I want to know why it works. :))

:confused: <- I love these little faces...

Thanks a lot.

It should be

Code:

---

BYTE *get_pixel_add(int x, int y)
{
  WORD offset        = ( ((y *320 + x) );
  return &g_vgamemory[offset];
}

---

I'm not sure I understand what you want to do. Why do you want to return a pixel's address? Pehaps you are asking how can you return the value of a pixel at a specific address?

BYTE *Screen=(BYTE *)MK_FP(0xa000,0);

BYTE GetPixel(WORD x,WORD y)
{
return Screen[(y<<6)+(y<<8)+x];
}

If you just want to return a pixel's address, you know that the segment is going to be 0xA000 for mode 13h. All you need to do is compute the offset like you have been doing, and return that value. Again, I see little or no use for such a function.

WORD GetPixelAddress(WORD x,WORD y)
{
return ((y<<6)+(y<<8)+x);
}

This is the same value you will get from your x,y to offset conversion.

Bubba,
Yes, as I said, I'm not going to be using it. I'm just
'playing around.' Also, I did mean the value, but I was
going to get that after I got the address of the pixel.

value = Get_Pixel_Value(Get_Pixel_Address(x, y));

Your way seems easier... Stupid Brain... Why can't you
be more like Bubba's??

Nick,
Wait, need explanation. Why would it be type BYTE? Doesn't
a BYTE only hold a value beteen 0-255? There are more
addresses than that. Eh, I'm so-freaking-confused. Please,
please explain.

I have never programmed in mode 16 DOS myself I use the SDL.

What you could do look up the declaration of vgamemory ?

Here is why I guessed BYTE

In Mode 16 each pixel takes up a byte of video memory.
That byte is a index into a palette table right? So it would
make sense that vgamemory is BYTE. In mode 16 you
only get 256 simutanous colors but of those colors
you have alot more.

I can't be absoulty sure though it could be
void* vgamemory;

and then the programmer would do something like

BYTE* pixels = vgamemory; /* in c */
pixels[4] = 1;


Now if a compiler can't optimize y * 320 + x
I want a refund!

You need to be careful though I think messing with pixels will probably be slow anyways.

returning BYTE* not a BYTE so there are more addresses.





I dos all pointers stored in two bytes, 2^16 equals


a bigger number.

for the sake of saying, you can get major speed gains by (using the aforementioned bitshifting) as well as using #define P_PIXEL(x,y,c) *(VGA_PTR + (y<<8) + (y<<6) + x) = c;

Your #define will greatly speed up the code but ...

Every decent c compile should be able to optimize
320*x + y


calc_value:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx
movl %edx, %eax
sall $2, %eax
addl %edx, %eax
sall $6, %eax
addl 12(%ebp), %eax
popl %ebp
ret

here is calc_value in c

int calc_value(int x, int y)
{
return 320*x + y;
}

I should also note I used gcc with no optimizations, I don't
know enough about assemlbly to program in it but I can tell
there's no imul or whatever.

Just make sure you don't write code like
pow(base, 2) when you need speed!

13h is 256 color, you are telling it where the pixel is, then for some reason returning the adress in memory of the pixel, if your trying to get the color:

char getcolorofpixel(int x,int y)
{
return v_gamemory[(y*320)+x];
}



SPH:rolleyes: :)

Thanks doubleanti. I did not include that because I thought be more confusing for our friend but maybe I was wrong.

As for relying on the compiler for optimizations:

Never rely on the compiler to do the programmer's job. If you *want* speed, then code fast optimized functions. If you *hope* to get speed, then ignore all of this, and just use compiler optimizations.

As for the data type question:

Again:

• If you are returning the address or offset of the pixel then the data type is WORD or unsigned int - 0h to FFFFh.
  
• If you are returning the *value* at address or offset in mode 13h, the data type is BYTE or unsigned char - 0h to FFh.

Quote:

---

13h is 256 color, you are telling it where the pixel is, then for some reason returning the adress in memory of the pixel, if your trying to get the color:

char getcolorofpixel(int x,int y)
{
return v_gamemory[(y*320)+x];
}

---

You are not returning the address in memory, you are returning the value at the address in memory.

If you have more questions, then go to www.brackeen.com for more info.

Quote:

---

then for some reason returning the adress in memory of the pixel

---

Friggin... Did you not read my original post? I said I
wasn't going to use this for my game, and that I was just
trying to become more 'comfortable' with pointers. There
isn't a reason for returning the address. There isn't a use.
There isn't anything. Ack! I'm going to cry...

Anyway, my original intention was to get the color of a
specific pixel. But, since I'm an idiot and my brain doesn't
seem to work like yours; instead of just returning the
color, for some reason I decided I would return the address
of a pixel and pass that address through another
function to get the color.

This is why I get nervous about posting questions. People
become so judgemental of what I'm trying to do. I'm
embarrassed of my programming-techniques.

Forget it, whatever... Bye.

don' tbe embarrased or woried to post sombodys alwasy gonna hassle ya... they ignore stuff like that without thinking

I'm embarrassed of my programming-techniques.

don't be embarrassed of you programming techniques.

i was embarrassed at first too and i am still a little unsure of my abilities though there is no reason... be proud i can't program in 13h heck i don't even understand what it half of it means... all i know is its some kind of assembler graphical mode or something...
just ignore them...

and for the smartys who might laugh at my ignorance

I plan on learnig asm and all the low level interrupts and all that crap AFTER if finish mastering C/C++ or at least reach the expert level... and im probably closer to it than you so suck on that...:D

Did not intend for my post to seem as though I was making fun of you, because I was not. We all have to start somewhere and even though I'm currently working on DirectX and ActiveX programming, I still have my DOS C compiler and use it for mode 13h, sound, VESA, memory management, etc.

Nobody here called you stupid nor did they imply that in their posts. That is not what this board is here for. All of us are here to help each other through various programming problems, whatever they might be. Granted, there are those here who know just about everything about C++, although I personally feel that it takes a lifetime to master C/C++, and there are those here who are just starting out. Whatever the case, we are here to help you.

I myself have also coded things just to see how something works or if I could pull it off. That is how you learn the language and how you learn different techniques and optimizations.

Don't be nervous or scared to post here. If you don't understand something, then just say that and everyone will/should understand and will help you.

There are far too many well-meaning members of this board to dismiss the whole board as being high and mighty know-it-all's. It has been my experience that most of the members are here to help, not to make fun of someone else's lack of knowledge.

Hi Hope this helps this from my ModeX Game lib ElibX to get the full Header goto: http://www.lrs.8m.com and go under the Products menu and download and enjoy. =)

#include <stdio.h>
#include <Conio.h>

#define No 0
#define Yes 1

char *Screen=(char *)0xA0000000L;

int Set_Mode(int mode)
{
asm MOV ax,mode;
asm INT 10h;
return No;
}

char Get_Pix(int x, int y, char *lc)
{
return(*((char *)lc+(320 * y)+ x));
}

int Plot(int x, int y, int c, char far *sc)
{
*((char*)sc+(320*y)+x)=c;
return No;
}

int rCol;

int main()
{
Set_Mode(0x13);
Plot(40,40,40,Screen);
rCol=Get_Pix(40,40,Screen);
printf("rCol var = %d\n",rCol);
if(rCol==40)printf("Color is 40");
getch();
Set_Mode(0x3);
return 0;
}

Signed: Tazar The Demon :cool: