Printable View
In tetris, when you get a line, you need to delete that line and make everything on top of that object fall down....
My question is, how can you clear a certain area of your screen? Is there an eraser function with coordinates attached? How can I accomplish this?
you could just draw a rectangle
something like glQuad or glPoly. I haven't done much openGL lately. Not sure I would even use openGl for something as trivial as a 2d game like tetris.
That depends on how you set it up. The way I would do it would be to have a bunch of quads make up the different shapes in the game. Then when I row gets full I just delete the quads on that row.
You do this in your render function. You should be redrawing the screen each time based on the array in memory. So if you delete a row in memory...it won't show up on screen. To make the other blocks fall you simply need to add code that if a block is above a cell that is open...it falls. The rate at which it falls can be determined by a parameter to the function or some other method. Note that you can handle the blocks falling at a set rate, and the blocks falling down to fill gaps with the same function using this method.
uhg, screen display arrays, scarryyyyyy....
I like the idea of drawing a black rectangle over the objects i want to "remove"
Right now, my shape functions are made of up multiple quads,
in the square the quads are set up seperately to form a 4 block square, maybe I can clear any quads at a certain area depending on where the line was made
Bubba's explanation is in fact the correct way to use opengl though.
oh the cold truth :(
I never worked with arrays that in depth yet, nor with pointers to memory or anything like that, I know how to use them, just not well
it's not so much an "array" concern. Just that you need a render() function of sorts that happens repeatedly. It should draw everything that is intended to be on the screen, every time. You may store that in an array or in the case of stuff that doesn't change you can just do certain instructions every time. It's just that opengl is an animation tool. Animation means frame after frame. And you have to draw those frames.
well, i dunno what you mean by frame by frame, because you can move objects in 3d space without redrawing them....
Regardless, I basically need to make a function that renders over all my other render functions, it is the god of all render functions...
it renders what is inside my "game area" render function, and determines what is allowed in and what isnt :D
I find it strange that I cant make a simple if statement
if line = full
clear anything less than the right end of the game but greater than the left end of the screen
Ummmmm...how can you move stuff without redrawing??? It is all memorybased....move something and you change something in memory (at least how I understand it). Everytime you change something in opengl you need to redraw it.
eh, i guess, i didn't realize changing the translate f actually deleted/redrew the object...
I thought that was what seperated turbo C++ graphics from OpenGL
the translate function moves the position of the coordinate system. It doesn't draw anything.
right, so when u change the translatef of a cube for instance, you aren't redrawing the cube, but you are moving it in 3d space...
Right?
But you need to draw after you translate for it to show up.
There is no way you can get something to move without redrawing!
no. you don't "translate a cube" you translate the coordinate system. There is no cube until you draw it.Quote:
Originally Posted by Shamino
so everytime you change the translate for the cube, it redraws, cuz theres a difference between your entire screen translating and just the cube
You need to redraw it yourself.
There is no such thing as "change the translate for the cube" in openGL because there is no cube within opengl. All that's within opengl is the matrix stack (position/rotation/scale). Nothing is there until you give it drawing instructions.Quote:
Originally Posted by Shamino
this thread has gone completely offtopic...
I really think you have no Idea at all what I'm talking about, and nor do I you....
Listen. It's simple.
- Draw everything in memory
- Blit everything from memory to screen
- Wash, rinse, repeat ad nauseum
Translating an object and all of those topcis are simple, very simple, 3D graphics fundamentals. If you do not understand them I suggest reading a book about 3D mathematics. There is no way possible we could explain 3D in one thread. Do yourself a favor and drop the game idea for now, purchase a book or two, and when you have compiled enough 3D knowledge....apply it and create your game.
Otherwise all of our posts will just lead to more questions.
I understand perfectly translating 3d objects and drawing them n everything, i made pong! :d but what you are suggesting is something i've never done before
Based on your responses in this thread I don't think you do.Quote:
I understand perfectly translating 3d objects and drawing them n everything, i made pong! :d but what you are suggesting is something i've never done before
Evryone knows about double buffering and yet you act as if it is a foreign topic here. Also you want to perform everything on the front buffer - as in erasing rows of blocks, etc. That is not the proper way to use OpenGL.
In Direct3D you would have to do the following to get a pointer to the front buffer.
- Get an interface pointer to the swap chain.
- Get an interface pointer to the front buffer via the swap chain interface
- Get a pointer to the actual surface that is the front buffer by locking the surface.
- Render to the front buffer
- Unlock the front buffer
This would result in major slowdowns. Anytime you must lock the buffer, you are probably not doing something right. And while steps 1 and 2 can be done beforehand and are not required each frame, locking and unlocking the buffer even just once per frame is too much.
Everything in computer graphics is done via the back buffer. You render to the back buffer and then present it to the front buffer.
ahhh, the buffers are foreign to me, this is true, I know how to draw objects, yes... but the buffer thingy is quite foreign to me...
I understand what you are saying bubba i think... the back buffer is kinda like what you have drawn into memory, and the front buffer is only things you want to bring out of memory onto the actual screen... You are correct, I have been doing it wrong, I've been doing everything on the front buffer, nothing has been thrown into memory except for textures...... Thanks for this insight :)
when I learned how to draw objects from NeHe, (up to lesson 7 now) he never explained drawing objects to the back buffer and then presenting them to the front buffer like that... Maybe i'm just not far enough along.....
I've been using OpenGL like turbo C++ graphics :D
OpenGL does that for you. There is no need to worry about backbuffer and stuff, NeHe's tutorials does exactly that.
with call to any of the glVertex functions you draw to the backbuffer, this is then braught to the front when you call SwapBuffer (I think it is).
I think it is automatically drawn on the front though, i'm thinking my problem includes taking things from the front buffer if I don't need them on the screen
You don't want to do that!Quote:
Originally Posted by Shamino
Draw EVERYTHING to the back buffer
swap buffers (back buffer becomes the front buffer (is drawn to the screen)
repeat.
No! OpenGL automatically draws to the back-buffer!! Try this so you can actually see that this is true: Comment out the call to the function SwapBuffers, then you will see that nothing gets drawn, sooooo that means it has been drawn to the backbuffer and is then braught to the front when you call SwapBuffers!
I don't even know how to just draw to the backbuffer...
So confused, can someone take this to instant messager with me, or private messages?
IM me at Shamino45...
or PM me with a little help
But for [beep] sake!!!! YOU DRAW TO THE BACKBUFFER ALREADY!!!! OPENGL DOES THIS FOR YOU!!!!! You dont need to worry about this.
Haha, no one is going to want to talk to you via IM because you just can't seem to grasp the basics! Re read this whole thread and read it over and over until you understand. Then if you have another question, ask.
This is the result of people jumping into graphics programming without even understanding what a buffer is.
A buffer is the 'virtual screen' in memory. I hope you know that all pixels are represented by DWORDs or unsigned integers (in 32-bit color and in 32-bit code). Since the actual video memory is simply an area of memory mapped I/O in the computer, you can mimick this 'screen' by creating your own buffer of DWORDs the same exact size as the video buffer.
The only thing that makes the 'screen' what you see is the fact that the card scans the area of memory deemed to be the 'screen' DWORD by DWORD hundreds of times per second - actually much faster than that. The card translates the RGB values into the correct analog voltages and sends them to the monitor. Some monitor's and some cards are pure digital depending on whether you have a flat screen array of transistors or an analog CRT.
The screen may look two dimensional on the monitor, but in memory it's just one long huge line of numbers. To plot a pixel at the correct location you must use these:
DWORD offset=y*(width*(sizeofdatatype))+x;
Note in DirectX and OpenGL (width*sizeofdatatype) has been replaced by something called buffer pitch. This basically says how many bytes of data exist in one scan line. The reason for pitch is because video manufacturers figured out that aligning the data on certain boundaries is much faster and more in tune with the architecture of the system as well as their GPU.
So in the old DOS days here are the size of some of the screens:
256 colors
640x480x256 colors - (640*480)
800x600x256 colors - (800*600)
To make a buffer for 640x480x256 colors you need to first figure out the data type being used. Since 256 color is simply paint by the palette number, all colors can be represented by 1 byte. Each RGB can be from 0 to 32 but only 256 distinct RGB triplets are allowed at any one time.
That code will fail in real DOS mode however because there is not enough memory to hold the data. I will not explain here the differences between 16-bit programming and 32-bit. Do some research.Code:typedef unsigned char BYTE;
BYTE far *Buffer=new unsigned char[(unsigned long)(640*480)];
To plot a pixel in that 'virtual screen' you would do this:
Surface is simply a BYTE far pointer that points to either buffer or screen.Code:#define XYTOMEM (x,y,pitch) (unsigned long)((y)*(pitch)+(x))
void Pixel(int x,int y,BYTE color)
{
Surface[XYTOMEM(x,y)=color];
}
This is a simpe mode 13h unit. Try it in Turbo C++ and see what you get. It's old, but it might help you understand what the heck a backbuffer is. The keyword FAR is not used anymore - but you still must use it when coding for 16-bit pure or emulated DOS. It informs the compiler that the pointer to the memory does not exist in our segment - in exists outside of our current segment. To explain that I would have to explain assembly language programming and I'm also not going to do that.
This will stick the computer in old school DOS 320x200x256 color mode and will setup the screen, back buffer, and current buffer pointer.Code:#ifndef CVIDEO
#define CVIDEO
#define TRUE 1
#define FALSE 0
class CVideo
{
protected:
//Pointer to actual screen - video memory
BYTE far *Screen;
//Pointer to back buffer - virtual screen
BYTE far *Buffer;
//Pointer to current pointer being used
BYTE far *Surface;
unsigned int Width;
unsigned int Height;
unsigned int Pitch;
//Current drawing mode
BYTE BufferMode;
public:
CVideo(void):Screen(0),Buffer(0),Surface(0),Width(0),Height(0),Pitch(0) {}
virtual ~CVideo(void)
{
if (Buffer)
{
delete [] Buffer;
Buffer=0;
}
}
BYTE SetMode13h(void)
{
REGS regs;
regs.x.ax=0x10;
int86(0x10,& regs, & regs);
Width=320;
Height=200;
Pitch=Width; //pitch and width synonymous in this mode
Screen=(BYTE far *)MK_FP(0xA000,0);
Surface=Screen;
Buffer=new BYTE[64000L];
if (Buffer)
{
return true;
} else return false;
}
void Pixel(int x,int y,BYTE color
{
Surface[XYTOMEM(x,y)=color];
}
BYTE far *GetBuffer(void) {return Buffer;}
BYTE far *GetScreen(void) {return Screen;}
BYTE far *GetSurface(void) {return Surface;}
void Flip(void)
{
//No vsync here
//Copy back buffer to screen
memcpy((BYTE far *)Screen,(BYTE far *)Buffer,64000L);
}
void Flip16(void)
{
asm {
push ds
les di,[Screen]
lds si,[Buffer]
mov cx,32000d
rep movsw
pop ds
}
}
void Flip32(void)
{
asm {
db 66h
push ds
db 66h
les di,[Screen]
db 66h
lds si,[Buffer]
db 66h
mov cx,32000d
db 67h
rep movsw
db 66h
pop ds
}
}
void SetBufferMode(BYTE mode=TRUE)
{
if (mode)
{
Surface=Buffer;
BufferMode=TRUE;
}
else
{
Surface=Screen;
BufferMode=FALSE;
}
}
BYTE GetBufferMode(void) {return BufferMode;}
void CLS(BYTE color)
{
BYTE far *ptrSurface=0;
if (BufferMode)
{
ptrSurface=Buffer;
} else ptrSurface=Screen;
asm {
les di,[ptrSurface]
mov cx,32000d
mov ah,[color]
mov al,[color]
rep stosw
}
}
//inlined
unsigned int XYTOMEM(int x,int y)
{
return (y<<8)+(y<<6)+x;
}
};
#endif
You can add functions to the class to draw lines, circles, bitmaps, etc. The only function I'm leery of is Flip32 which is an attempt to use 32-bit code in a 16-bit environment. If it works, it should copy 4 pixels at a time to the screen instead of 2 like Flip16. Flip simply copies 1 byte at a time. Theoretically Flip16 is twice as fast as Flip and Flip32 is twice as fast as Flip16 or four times as fast as Flip. But I'm not positive the code will work. It's been a LONG time since the DOS days.
Play with this code. Set the screen up by calling SetMode13h. Then clear the screen by calling CLS(BYTE color). This will clear the screen if BufferMode is FALSE and will clear the buffer if it is TRUR. The parameter is the color the screen will be cleared to. Set the buffer mode to TRUE by calling SetBufferMode(TRUE). Draw some pixels. Run it. Nothing shows up. This is because you are drawing to a back buffer - a portion of memory that looks just like the screen, but isn't. Now call Flip() after you draw and everything should show up. This is what OpenGL and Direct3D are doing for you.
Drawing to the front buffer, in most cases, is not needed.
This code should work with that class:
This should display a white dot in the center of the screen.Code:
#include "CVideo.h"
#include <conio.h>
#include <stdio.h>
CVideo Display;
int main(void)
{
Display->SetMode13h();
Display->SetBufferMode(TRUE);
Display->CLS(0);
Display->Pixel(160,100,15);
Display->Flip();
getch();
return (0);
}
Sorry for such a long post, but to show you buffers in DirectX code is even uglier than what I just posted...and none of it would show you how it works - just how to do it in DirectX.
This code will show you EXACTLY what is going on. Download Turbo C++ 1.0 from www.inprise.com and mess with it. Then go back to OpenGL and please - rethink what you are doing.
If the code doesn't work, let me know what's wrong with it. I wrote it sitting here so I'm sure there are some errors.
Yah, exactly, jumping into OpenGL before gaining a solid background of memory and buffers and things like that...
Theres a lesson to be learned here.. I'll worry about it later :rolleyes:
So what I'm doing is this....
1. Drawing to the backbuffer.
2. Bringing things I want from the backbuffer to the "real" screen.
3. Taking away from the "real" screen, and throwing back into memory what I don't need.
I believe I understand the concept now, I was never taught, self learning always has its flaws, you learn things you are directly interested in. Everyone is acting like I should magically know these things, I've only been programming graphics for 2 months, and doing C++ for 8 months....
Hm, I aught to pick up a good book.. I'm so cheap though :p
You don't 'take away' from the real screen.
Every time you send the back buffer to the front buffer the front buffer is over written. Think of it like a cartoon how it is made up of frames, when played the pictures come to life one frame at a time. All you are doing in drawing one frame at a time to the back buffer and then you are displaying it.
hmm, can anyone contact me via IM or Email?
[email protected]
or
Shamino55 on AOL