Easy GL2D
-
- Posts: 84
- Joined: Sun Apr 11, 2010 10:43 am
Re: Easy GL2D
Sure I'd post any updates here. ;*)
BTW, I would use the latest libnds though since all it takes is to add just one line of code.
BTW, I would use the latest libnds though since all it takes is to add just one line of code.
Re: Easy GL2D
Hi Relminator,
I think I might (maybe) have found another bug in your code. Thought I'd post and see what you think.
Take a look at the following simple code:-
glLine ( 0, 0, 16, 0, RGB15( 31, 0, 0)); // 16 pixel red
glLine ( 0+16, 0, 16+16, 0, RGB15( 31, 31, 0)); // 16 pixel yellow
This draws 2 lines each 16 pixels each, one is red, one is yellow and they are both touching. Simple eh?
The next code here:-
glLine ( 0, 100, 16, 100, RGB15( 21, 0, 0));// 16 pixel red
glLine ( 0+16, 100, 16+16, 100, RGB15( 21, 21, 0)); // 16 pixel yellow
is the same but starting 100 pixels in the Y direction. With me so far?
Now the problem I am having starts here:-
glLine ( 1, 1, 16, 1, RGB15( 31, 0, 0)); // 15 pixel red?!
glLine ( 1+16, 1, 16+16, 1, RGB15( 31, 31, 0)); // 15 pixel yellow?!
This code here only seems to draw 15 pixels, not 16 as you might expect. There is a gap between 2 lines because the final pixel is missed. It seems that unless you start drawing from 0 in the x direction it always forgets to draw the final pixel. I am not sure is this is a bug or feature but since the behaviour is different when x is not equal to 0 I would say perhaps this is a bug.
[edit]
Well after some more testing and looking at other commands. glboxFilled is the same result and glbox has 16 pixels but all with a +1 offset in the X direcion.
glLine ( 1, 1, 16, 1, RGB15( 21, 0, 0)); // 15 pixel red
glLine ( 1+16, 1, 16+16, 1, RGB15( 21, 21, 0)); // 15 pixel yellow
glBox ( 1, 2, 16, 2, RGB15( 21, 0, 0)); // 16 pixel red +1 xoffset
glBox ( 1+16, 2, 16+16, 2, RGB15( 21, 21, 0)); // 16 pixel yellow +1 xoffset
glBoxFilled ( 1, 3, 16, 3, RGB15( 21, 0, 0)); // 15 pixel red
glBoxFilled ( 1+16, 3, 16+16, 3, RGB15( 21, 21, 0)); // 15 pixel yellow
I guess this is just a feature of trying to map pixels accurately textured to a quad which going to create a bit of pixel jumping since it isn't true pixel plotting to the screen coordinates in memory.
I think I might (maybe) have found another bug in your code. Thought I'd post and see what you think.
Take a look at the following simple code:-
glLine ( 0, 0, 16, 0, RGB15( 31, 0, 0)); // 16 pixel red
glLine ( 0+16, 0, 16+16, 0, RGB15( 31, 31, 0)); // 16 pixel yellow
This draws 2 lines each 16 pixels each, one is red, one is yellow and they are both touching. Simple eh?
The next code here:-
glLine ( 0, 100, 16, 100, RGB15( 21, 0, 0));// 16 pixel red
glLine ( 0+16, 100, 16+16, 100, RGB15( 21, 21, 0)); // 16 pixel yellow
is the same but starting 100 pixels in the Y direction. With me so far?
Now the problem I am having starts here:-
glLine ( 1, 1, 16, 1, RGB15( 31, 0, 0)); // 15 pixel red?!
glLine ( 1+16, 1, 16+16, 1, RGB15( 31, 31, 0)); // 15 pixel yellow?!
This code here only seems to draw 15 pixels, not 16 as you might expect. There is a gap between 2 lines because the final pixel is missed. It seems that unless you start drawing from 0 in the x direction it always forgets to draw the final pixel. I am not sure is this is a bug or feature but since the behaviour is different when x is not equal to 0 I would say perhaps this is a bug.
[edit]
Well after some more testing and looking at other commands. glboxFilled is the same result and glbox has 16 pixels but all with a +1 offset in the X direcion.
glLine ( 1, 1, 16, 1, RGB15( 21, 0, 0)); // 15 pixel red
glLine ( 1+16, 1, 16+16, 1, RGB15( 21, 21, 0)); // 15 pixel yellow
glBox ( 1, 2, 16, 2, RGB15( 21, 0, 0)); // 16 pixel red +1 xoffset
glBox ( 1+16, 2, 16+16, 2, RGB15( 21, 21, 0)); // 16 pixel yellow +1 xoffset
glBoxFilled ( 1, 3, 16, 3, RGB15( 21, 0, 0)); // 15 pixel red
glBoxFilled ( 1+16, 3, 16+16, 3, RGB15( 21, 21, 0)); // 15 pixel yellow
I guess this is just a feature of trying to map pixels accurately textured to a quad which going to create a bit of pixel jumping since it isn't true pixel plotting to the screen coordinates in memory.
Re: Easy GL2D
No need to change gl2d.h or libgl2d.a?
I mean for everything that I code,do I have to put this?
vramSetBankA( VRAM_A_TEXTURE );
vramSetBankE(VRAM_E_TEX_PALETTE);
or maybe add?
vramSetBankE(VRAM_E_TEX_PALETTE);
I had the same problem as ENAY.
4 Color sprites and 256 color sprites are rendered black on the ds,no$gba,dsmume and ideas
and I can't use 16bit sprites since I don't know how to set the transparent colors.
I mean for everything that I code,do I have to put this?
vramSetBankA( VRAM_A_TEXTURE );
vramSetBankE(VRAM_E_TEX_PALETTE);
or maybe add?
vramSetBankE(VRAM_E_TEX_PALETTE);
I had the same problem as ENAY.
4 Color sprites and 256 color sprites are rendered black on the ds,no$gba,dsmume and ideas
and I can't use 16bit sprites since I don't know how to set the transparent colors.
-
- Posts: 84
- Joined: Sun Apr 11, 2010 10:43 am
Re: Easy GL2D
Yep:
Just ad that code and your done.
Enay, thanks for the heads up. I'll fix it.
Code: Select all
vramSetBankE(VRAM_E_TEX_PALETTE);
Enay, thanks for the heads up. I'll fix it.
Re: Easy GL2D
Hi Relminator,
Thanks again for your post, I think I have found some more bugs in your library. Well,it is certainly odd behaviour I was having and I managed to pin it down with your primitives. I am having problems using dual screens, the screens flip and never return back. I have finally isolated the problem, maybe there is a memory leak or something somewhere?
As explained in the code when I use glBoxFilled it fails when I try to draw 22 boxes but not at 21 boxes or less. PING! Bottom and top screens are reversed!
glPutPixel is even odder, works ok on 23 dots or less, but on 24 it will go PING after a few seconds of waiting, starts to fail faster and faster up till 34ish and fails almost instantly at 35 dots. I can't figure out why it is doing that
Anyway take a look at the following code below that I modified from dual_screen DS code:-
Thanks again for your post, I think I have found some more bugs in your library. Well,it is certainly odd behaviour I was having and I managed to pin it down with your primitives. I am having problems using dual screens, the screens flip and never return back. I have finally isolated the problem, maybe there is a memory leak or something somewhere?
As explained in the code when I use glBoxFilled it fails when I try to draw 22 boxes but not at 21 boxes or less. PING! Bottom and top screens are reversed!
glPutPixel is even odder, works ok on 23 dots or less, but on 24 it will go PING after a few seconds of waiting, starts to fail faster and faster up till 34ish and fails almost instantly at 35 dots. I can't figure out why it is doing that
Anyway take a look at the following code below that I modified from dual_screen DS code:-
Code: Select all
#include <nds.h>
#include <stdio.h>
#include <gl2d.h>
// some useful defines
#define HALF_WIDTH (SCREEN_WIDTH/2)
#define HALF_HEIGHT (SCREEN_HEIGHT/2)
#define BRAD_PI (1 << 14)
// Declarations
void initSubSprites(void);
/******************************************************************************
MAIN
******************************************************************************/
int main( int argc, char *argv[] )
{
// Set it to my favorite mode
videoSetMode(MODE_5_3D);
videoSetModeSub(MODE_5_2D);
// init oam to capture 3D scene
initSubSprites();
// sub background holds the top image when 3D directed to bottom
bgInitSub(3, BgType_Bmp16, BgSize_B16_256x256, 0, 0);
// Initialize GL in 3d mode
glScreen2D();
int key;
// our ever present frame counter
int frame = 0;
int no_of_boxes = 21;
while( 1 )
{
scanKeys();
key = keysDown();
if( (key & KEY_DOWN) || (key & KEY_RIGHT) || (key & KEY_UP) || (key & KEY_LEFT) )
{
no_of_boxes++;
}
// increment frame counter
frame++;
// wait for capture unit to be ready
while(REG_DISPCAPCNT & DCAP_ENABLE);
// Alternate rendering every other frame
// Limits your FPS to 30
if((frame & 1) == 0)
{
lcdMainOnBottom();
vramSetBankC(VRAM_C_LCD);
vramSetBankD(VRAM_D_SUB_SPRITE);
REG_DISPCAPCNT = DCAP_BANK(2) | DCAP_ENABLE | DCAP_SIZE(3);
// No drawing in bottom screen
}
else
{
lcdMainOnTop();
vramSetBankD(VRAM_D_LCD);
vramSetBankC(VRAM_C_SUB_BG);
REG_DISPCAPCNT = DCAP_BANK(3) | DCAP_ENABLE | DCAP_SIZE(3);
glBegin2D();
glBoxFilledGradient( 0, 0, 255, 191,
RGB15( 0, 31, 0 ),
RGB15( 31, 31 , 0 ),
RGB15( 0, 0, 0 ),
RGB15( 31, 0, 0)
);
int loop = 0;
// draw a black box
//for (loop = 0 ; loop < no_of_boxes ; loop++)
for (loop = 0 ; loop < 24 ; loop++)
{
/*glBoxFilled( 200, 10,
250, 180,
RGB15(0,0,0)
);*/
//glBoxFilled fails at 22 boxes but not at 21 boxes or less
//glPutPixel fails after a few seconds at 24, starts to fail faster and
//faster up till 34ish and fails instantly at 35, but not at all on 23 boxes or less
//glPut
glPutPixel( 20,20,RGB15(0,0,0));// fails at
}
glEnd2D();
}
glFlush(0);
swiWaitForVBlank();
}
return 0;
}
//-------------------------------------------------------
// set up a 2D layer construced of bitmap sprites
// this holds the image when rendering to the top screen
//-------------------------------------------------------
void initSubSprites(void)
{
oamInit(&oamSub, SpriteMapping_Bmp_2D_256, false);
int x = 0;
int y = 0;
int id = 0;
//set up a 4x3 grid of 64x64 sprites to cover the screen
for(y = 0; y < 3; y++)
for(x = 0; x < 4; x++)
{
oamSub.oamMemory[id].attribute[0] = ATTR0_BMP | ATTR0_SQUARE | (64 * y);
oamSub.oamMemory[id].attribute[1] = ATTR1_SIZE_64 | (64 * x);
oamSub.oamMemory[id].attribute[2] = ATTR2_ALPHA(1) | (8 * 32 * y) | (8 * x);
id++;
}
swiWaitForVBlank();
oamUpdate(&oamSub);
}
-
- Posts: 84
- Joined: Sun Apr 11, 2010 10:43 am
Re: Easy GL2D
For primitives, there's really no way to have a memleak as they don't allocate stuff. I fact even the glSprite routines never allocate anything so memleak should not be an issue.
I'll look into it. I may have uploaded an older build.
I'll look into it. I may have uploaded an older build.
-
- Site Admin
- Posts: 1986
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: Easy GL2D
Why does glPutPixel even exist?
Re: Easy GL2D
To each its own, I guess. Everybody has a different way of doing things. Inefficient? Quite possibly, yet still an alternative.
You could also ask why does OpenGL still support glBitmap() in a world where 3D is not only king, it's the only thing that exists...
You could also ask why does OpenGL still support glBitmap() in a world where 3D is not only king, it's the only thing that exists...
-
- Site Admin
- Posts: 1986
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: Easy GL2D
glBitmap is useful for GUIs and HUDs - it's basically a simple billboard function, glPutPixel is just crazy.
Re: Easy GL2D
Hi guys,
Wow, quite a few posts since I last posted here. Did you manage to find anything out Relminator?
Well I have been using a workaround for now and as such things are going well, many thanks to you for making this useful library!
I'm about 60% done on my game, my first attempt at programming anything other than on a Windows platform. Took me ages to get started but now things are going much quicker than I thought.
I can't say I have used putpixel myself either. These days you can do pretty much everything using sprites. I can't really think of a situation these days where I would want to draw just dots in realtime.
Wow, quite a few posts since I last posted here. Did you manage to find anything out Relminator?
Well I have been using a workaround for now and as such things are going well, many thanks to you for making this useful library!
I'm about 60% done on my game, my first attempt at programming anything other than on a Windows platform. Took me ages to get started but now things are going much quicker than I thought.
I can't say I have used putpixel myself either. These days you can do pretty much everything using sprites. I can't really think of a situation these days where I would want to draw just dots in realtime.
Who is online
Users browsing this forum: No registered users and 0 guests