Simple Graphics...

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Simple Graphics...

Post by jason867 »

I've looked at the graphics samples in the sdk, but it's hard for me to understand completely. How does one simply plot pixels on the screen using x,y, and color? I know it probably involves taking those three values (color being made of a few values itself), making a hex number out of them, submitting that to an array or something, and then submitting that to the proper screen memory and flipping buffers and what not. But I'm confused on the exact specifics of what needs to be done and in what order. So if someone could just detail it for me, I would be greatly thankful.
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Re: Simple Graphics...

Post by Shine »

Write to graphics memory to plot pixels. You don't need to switch it, if you can life with flickering graphics update, otherwise draw to the screen which is currently not visible, wait for VSync and switch the visible screens. If this is all to complicated, use my Lua Player graphics module or use Lua :-)
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

Thanks for that lua stuff, I'll look at it, but I'm not sure you got what I meant. I know that to plot a pixel I have to write to the screen memory, and that I can write to two different sections and flip screens during vblanks to avoid screen flicker. What I need to know is like; where does the screen memory start? where does the second section start? What would be the best way to write to that memory? What format do I setup pixels to be? (rgb,bgr,ect.) How do I get the hex for the color I want? How do I combine x,y, and color into one hex number? How do I use dma's to switch screens fast?

Ultimately, I'd like to develop my own graphics.h file and have a plot pixel function that's very simple, something like this;
PlotPixel(x,y,r,g,b);
Also how exactly do I change video modes? which one does it default to?

Like I said, I looked at the graphic samples in the sdk, but I couldn't quite figure out how to do this? Although I could tell it was similiar to the way the gba worked.
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Post by Shine »

If you want to use 2D, you can use the sceDisplaySetMode to initialize the graphics and sceDisplaySetFrameBuf to set the start of the graphics buffer, which the PSP displays. There is 2 MB of VRAM, which can be used for this and which starts at 0x44000000. See the scr_printf.c in the SDK for an example and the SDK documentation, which pixelformats you can use with sceDisplaySetFrameBuf. The internal line size is 512 elements (512*2 bytes in 16 bit mode and 512*4 bytes in 32 bit modes), which you need to calculate the address for given x and y coordinates and to calculate the second frame buffer.

Getting the hex color of an pixel depends on the format, for the 16 bit format 5551 for example you can use this: u16 rgb = ((b>>3)<<10) | ((g>>3)<<5) | (r>>3) | 0x8000.

There are some more issues with cached and uncached access, which I don't know in detail, but with this information it should be possible for you to write your PlotPixel.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

Couple of other questions. For the r,g,b values, what are their maximums? 31?

I'm not sure what you mean by internal line size, could you elaborate on that?
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Post by Shine »

jason867 wrote:Couple of other questions. For the r,g,b values, what are their maximums? 31?

I'm not sure what you mean by internal line size, could you elaborate on that?
5551 means the number of bits, so in 5551 format you have 5 bits for each color component and 1 bit for alpha channel information, which means yes, 31 is the maximum for this pixelformat. For 8888 you have 8 bits per color component.

With internal line size (I don't know if this is the official name) I mean the following: assuming your VRAM starts at "u16* vram" for 5551 mode. Then the first 480 pixels are from vram[0] to vram[479], but the second visible line starts from vram[512], because the PSP used some invisible padding bytes from vram[480] to vram[511], perhaps for faster blitting.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

I see what you mean. I've gotten this far in the plotpixel function, although this was the easy part.

void PlotPixel(int x,int y,int r,int g,int b)
{
int color=0;
color=((b>>3)<<10) | ((g>>3)<<5) | (r>>3) | 0x8000;
x=x*(SCR_WIDTH/*-1*/)
y=y*(SCR_HEIGHT/*-1*/)
}

the '/*-1*/' were part of the source code that I got these lines from. I'm not sure if they're always needed, or if they were put in there for that case only.

I'm still not sure about how the next part of this function will work. I know I could write directly to the draw buffer. But, for me anyways, it seems easier to understand if I simply create a 2d array ([512][272]) to which I would put the hex color value at [x][y], and once I'm finished with the screen, or during vblank, I would write the array to the draw memory and flip buffers. Or I could skip the flip buffers part because the way I will be using plot pixel won't involve creating one frame at a time, it'll be more like changing the present frame a few pixels at a time. So you won't even notice flickering. I know it will most likely be slower too, but speed is not going to be an issue for me. When I need speed (which I doubt I ever will) then I'll figure out how to do it right. I could use hardware dma's to transfer the array to screen memory to help speed it up couldn't I?

One other quick question, does the psp have backgrounds or layers built into it's hardware, like the Gamboy Advance? Or must that be done through software alone? Just curious...

[Edit] By the way, if there's anything that I'm wrong on in here, please let me know...
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Post by Shine »

Looks like you don't have any clue about what you are doing, if you write such code after my example, which shows you where the pixels are, if you have a "u16* vram" C variable. Learn some C and come back then or use my Lua Player :-)
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

After reading that last post I became dis-hearted and gave up psp programming....

But I got to feeling better and decided to figure out this plot pixel thing. And I did! For the most part anyways, lol. I've got it plotting pixels on the screen. But there seems to be a small problem, the pixels are very dark and look like they're faded. There's no vibrance to them at all. Is this something to do with that alpha shading bit or something? I even tried producing pure white and only managed to get a light grey. Here's the code for my plotpixel function

void PlotPixel(int x,int y,int r,int g,int b)
{
int color=((b>>3)<<10) | ((g>>3)<<5) | (r>>3) | 0x8000;
u16 *address=VRAM+((((512)*PIXEL_SIZE)*y)+x);
*address=color;

}

If anyone knows what is the culprit or has some advice, please come forward, thank you.
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Post by Shine »

That's fine, finally you managed to plot a pixel :-) Maybe this is easier to read (assuming you have defined vram as u16* and initialized it with the right value):

Code: Select all

void PlotPixel&#40;int x,int y,int r,int g,int b&#41;
&#123;
    vram&#91;512*PIXEL_SIZE*y+x&#93; = &#40;&#40;b>>3&#41;<<10&#41; | &#40;&#40;g>>3&#41;<<5&#41; | &#40;r>>3&#41; | 0x8000;
&#125;
Regarding the intensity: What parameters do you pass to the function? In this function r, g and b is divided by 8, so you can pass from 0 to 255 in 16 bit mode.

If this doesn't help, perhaps you are in 32 bit graphics mode (but then the pixels should be much colored instead of grey)? You can test this, if you plot 240 pixel. If the line is only 1/4 of the screen width instead of 1/2 of the screen width, you are in 32 bit graphics mode.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

I thought that the r g b values could only go to 31? I'll try setting them at 255.

[EDIT] That's what the problem was! It was only going to 31, not 255...lol. Thanks for everything.

Now if I could only figure out 3D........"gets a massive migraine"
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Post by Shine »

jason867 wrote:I thought that the r g b values could only go to 31? I'll try setting them at 255.

[EDIT] That's what the problem was! It was only going to 31, not 255...lol. Thanks for everything.

Now if I could only figure out 3D........"gets a massive migraine"
You should really learn some C, but I'll try to explain it. In 16 bit mode the PSP graphics memory looks like this:

Code: Select all

16 bit&#58; pixel 0
next 16 bit&#58; pixel 1
...
The meaning of the 16 bits are like this:

Code: Select all

bit meaning
--------------
15  alpha bit
14  blue bit 4
13  blue bit 3
12  blue bit 2
11  blue bit 1
10  blue bit 0
9   green bit 4
8   green bit 3
7   green bit 2
6   green bit 1
5   green bit 0
4   red bit 4
3   red bit 3
2   red bit 2
1   red bit 1
0   red bit 0
And the line ((b>>3)<<10) | ((g>>3)<<5) | (r>>3) | 0x8000 means the following: shift b 3 bits right, which means, if you have 8 bits input value frm 0 to 255, after the shift it is 5 bit in the range 0 to 31, and shift the result 10 bits left (verify the table above to see that the 5 "b" bits then are at the right position), do the same with "g" (but shift only 5) and r and "or" all together, plus an alpha value (bit 15 = 0x8000). So I hope you understand it now.

For 3D take a look at the gu-samples in the PSPSDK.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

I knew that each r,g,b was represented by 5 bits. In GBA coding, the 15th bit wasn't used at all. Although I never did know what the

((b>>3)<<10) | ((g>>3)<<5) | (r>>3) | 0x8000

meant.

Another quick question. Whenever I use a while(!done) loop with nothing in the parenthesis's, and I press the home button, the psp doesn't go back to the main menu like it should. But whenever I actually have something within the parenthesis's, it works just fine when I press the home button. What's up with that? I thought you could use while loops with nothing in them just to make the program continuously run?
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
malaka
Posts: 3
Joined: Tue Aug 02, 2005 3:29 am

Post by malaka »

Let me add something about the shift operations.

Since they decal bits left or right (with no cycle) you can conveniently use/consider/see them as multiplications or integer divisions by a power of 2.

so ">>3" means "divide by 2^3" so divide by "8"
and "<<2" means "multiply by 2^2" so multiply by "4"

also be carefull of the possible side effects produced by those operations !

Exemple:
- you use an "unsigned char" (so 8bits) as variables type
- lets say it's got the value "1000 0000" (so 128 in decimal)
- if you leftshift this once (<<1), the "1" is gonna be lost and you'll end with 0.

Exemple 2:
- using the unsigned char type
- 2 [decimal] -> 0000 0010 [binary]
- after ((2>>2)<<2) you got 0 !!!
- after ((2<<2)>>2) you got 2

Exemple 3:
- using the unsigned char type
- 64 [decimal] -> 0100 0000 [binary]
- after ((64>>2)<<2) you got 64
- after ((64<<2)>>2) you got 0 !!!
- demomacking is not a crime -
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Post by Shine »

malaka wrote:- after ((64<<2)>>2) you got 0 !!!
This is wrong. Take a look at the ISO/IEC 9899:1999 C standard, chapter 6.5.7, "Bitwise shift operators":
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.

The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1*2^E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1*2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.
And for "integer promotion" you'll find an example in chapter 5.1.2.3, "Program execution", example 2:
EXAMPLE 2 In executing the fragment

char c1, c2;
/* ... */
c1 = c1 + c2;

the ‘‘integer promotions’’ require that the abstract machine and then add the two ints and truncate the sum. Provided overflow, or with overflow wrapping silently to produce the produce the same result, possibly omitting the promotions.
So this means, that this code:

Code: Select all

int main&#40;int argc, char** argv&#41;
&#123;
	unsigned char c = 64;
	c = &#40;c<<2&#41;>>2;
	printf&#40;"%i\n", c&#41;;
&#125;
prints "64".
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

Thanks for the explanations, but what about the while loop thing?
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Shine
Posts: 728
Joined: Fri Dec 03, 2004 12:10 pm
Location: Germany

Post by Shine »

jason867 wrote:Thanks for the explanations, but what about the while loop thing?
it's cooperative multitasking on PSP. You have to call some kernel function, like waitvblankstart, to give the kernel a chance to end your thread.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

So as long as I call a kernel function in the while loop (or I assume any loop for that matter) then home button should exit the program normally like it should, right?

[Edit]
I just put together a program that randomly draws lines of random color and length. It works, and runs blisteringly fast too. But it freezes after about 7 seconds of running, and shuts off the psp about 10 seconds after that. I looked at my code, but couldn't detect any errors. The line drawing algorythem was copied off of a line drawing tutorial I found on the web, it was free source in case you're wondering. I copied it and changed it to make it work on the psp and everything. But I can't figure out why it's freezing 7 seconds into the program. Here is the line code, I'm pretty sure the problem is in there, since all of the other code has been used numerous times for other things and always functions as expected. I looked at it too just in case. Here is the line drawing code;

Code: Select all

void PlotLine&#40;int x0,int y0,int x1,int y1,int r,int g,int b&#41;
&#123;
   int dy = y1 - y0;
   int dx = x1 - x0;
   float t = &#40;float&#41; 0.5;                      // offset for rounding

   PlotPixel&#40;x0,y0,r,g,b&#41;;
   if &#40;abs&#40;dx&#41; > abs&#40;dy&#41;&#41; // slope < 1
   &#123;
      float m = &#40;float&#41; dy / &#40;float&#41; dx;      // compute slope
      t += y0;
      dx = &#40;dx < 0&#41; ? -1 &#58; 1;
      m *= dx;
      while &#40;x0 != x1&#41;
      &#123;
         x0 += dx;                           // step to next x value
         t += m;                             // add slope to y value
         PlotPixel&#40;x0,&#40;int&#41;t,r,g,b&#41;;
      &#125;
   &#125;
   else // slope >= 1
   &#123;
      float m = &#40;float&#41; dx / &#40;float&#41; dy;      // compute slope
      t += x0;
      dy = &#40;dy < 0&#41; ? -1 &#58; 1;
      m *= dy;
      while &#40;y0 != y1&#41;
      &#123;
         y0 += dy;                           // step to next y value
         t += m;                             // add slope to x value
         PlotPixel&#40;&#40;int&#41;t,y0,r,g,b&#41;;
      &#125;
   &#125;
&#125;
Any help would be appreciated, thanks.
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Warren
Posts: 175
Joined: Sat Jan 24, 2004 8:26 am
Location: San Diego, CA

Post by Warren »

While I suspect you're drawing outside of the framebuffer, it would be more helpful if you posted all of the source that's making it crash.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

Ok, well, here's everything;

Here's main.c

Code: Select all

//////////////////////////////////////////////////////////////////////////////////////////
/* Random Line Generator Version 1.0
 * by Jason J. Owens
 * August 06, 2005 9&#58;35 AM
*/
//////////////////////////////////////////////////////////////////////////////////////////

// #includes
#include <pspkernel.h>
#include <pspdebug.h>
#include <pspdisplay.h>
#include <stdlib.h>
#include <Graphics.h>

PSP_MODULE_INFO&#40;"Random Line Gen Ver 1.0", 0x1000, 1, 1&#41;; // Defines module info.
PSP_MAIN_THREAD_ATTR&#40;0&#41;; // Defines the main thread's attribute value &#40;optional&#41;.

#define printf	pspDebugScreenPrintf // Defines printf, just to make typing easier.

int ExitGame = 0; // Gets set to '1' when getting ready to exit the game.

// Exit callback
int exit_callback&#40;int arg1, int arg2, void *common&#41;
&#123;
	ExitGame = 1;
	return 0;
&#125;

// Callback thread
int CallbackThread&#40;SceSize args, void *argp&#41;
&#123;
	int cbid;

	cbid = sceKernelCreateCallback&#40;"Exit Callback", exit_callback, NULL&#41;;
	sceKernelRegisterExitCallback&#40;cbid&#41;;

	sceKernelSleepThreadCB&#40;&#41;;

	return 0;
&#125;

// Sets up the callback thread and returns its thread id.
int SetupCallbacks&#40;void&#41;
&#123;
	int thid = 0;

	thid = sceKernelCreateThread&#40;"update_thread", CallbackThread, 0x11, 0xFA0, THREAD_ATTR_USER, 0&#41;;
	if&#40;thid >= 0&#41;
	&#123;
		sceKernelStartThread&#40;thid, 0, 0&#41;;
	&#125;

	return thid;
&#125;

int Random&#40;int high&#41;
&#123;
    return &#40;rand&#40;&#41; % &#40;high+1&#41;&#41;;
&#125;

// Here's the Main Function.
int main&#40;void&#41;
&#123;
	pspDebugScreenInit&#40;&#41;; // Initializes the Debug text output screen.
	SetupCallbacks&#40;&#41;; // Sets up the callback thread and returns its thread id.
	srand&#40;777&#41;;
	
	InitializeGraphics&#40;1&#41;;
	
	while&#40;!ExitGame&#41;
	&#123;
	    PlotLine&#40;Random&#40;480&#41;,Random&#40;272&#41;,Random&#40;480&#41;,Random&#40;272&#41;,
                Random&#40;255&#41;,Random&#40;255&#41;,Random&#40;255&#41;&#41;;
    &#125;
		
	sceKernelExitGame&#40;&#41;; // Returns PSP to the Main Menu.

	return 0; // Just for good practice.
&#125;

//////////////////////////////////////////////////////////////////////////////////////////
And here's my graphics header, Graphics.h;

Code: Select all

//////////////////////////////////////////////////////////////////////////////////////////
// Graphics.h Version 1.1
// By Jason J. Owens
// August 2, 2005 1&#58;28 AM
//////////////////////////////////////////////////////////////////////////////////////////

#ifndef __GRAPHICS__
#define __GRAPHICS__

// Function Prototypes
void PlotPixel&#40;int x,int y,int r,int g,int b&#41;;
void InitializeGraphics&#40;int mode&#41;;
void PlotLine&#40;int x0,int y0,int x1,int y1,int r,int g,int b&#41;;
//////////////////////////////////////////////////////////////////////////////////////////

// #defines
#define BUF_WIDTH &#40;512&#41;
#define SCR_WIDTH &#40;480&#41;
#define SCR_HEIGHT &#40;272&#41;
#define PIXEL_SIZE &#40;2&#41; /* change this if you change to another screenmode */
#define FRAME_SIZE &#40;BUF_WIDTH * SCR_HEIGHT * PIXEL_SIZE&#41;
//////////////////////////////////////////////////////////////////////////////////////////

// Global Variables
u16 *VRAM=&#40;0x44000000&#41;;
//////////////////////////////////////////////////////////////////////////////////////////

// Function Definitions
// Plots a pixel on the screen using x,y, and three 0-255 shade color attributes.
void PlotPixel&#40;int x,int y,int r,int g,int b&#41;
&#123;
    int color=&#40;&#40;b>>3&#41;<<10&#41; | &#40;&#40;g>>3&#41;<<5&#41; | &#40;r>>3&#41; | 0x8000; // Creates and stores color.
    u16 *address=VRAM+&#40;&#40;&#40;&#40;512&#41;*PIXEL_SIZE&#41;*y&#41;+x&#41;; // Caculates address of pixel.
    *address=color; // Writes color code into address of the pixel.
    
&#125;
//////////////////////////////////////////////////////////////////////////////////////////

// Plots a line according to the given values, startX, startY, endX, endY, and color&#58; R,G,B.
void PlotLine&#40;int x0,int y0,int x1,int y1,int r,int g,int b&#41;
&#123;
   int dy = y1 - y0;
   int dx = x1 - x0;
   float t = &#40;float&#41; 0.5;                      // offset for rounding

   PlotPixel&#40;x0,y0,r,g,b&#41;;
   if &#40;abs&#40;dx&#41; > abs&#40;dy&#41;&#41; // slope < 1
   &#123;
      float m = &#40;float&#41; dy / &#40;float&#41; dx;      // compute slope
      t += y0;
      dx = &#40;dx < 0&#41; ? -1 &#58; 1;
      m *= dx;
      while &#40;x0 != x1&#41;
      &#123;
         x0 += dx;                           // step to next x value
         t += m;                             // add slope to y value
         PlotPixel&#40;x0,&#40;int&#41;t,r,g,b&#41;;
      &#125;
   &#125;
   else // slope >= 1
   &#123;
      float m = &#40;float&#41; dx / &#40;float&#41; dy;      // compute slope
      t += x0;
      dy = &#40;dy < 0&#41; ? -1 &#58; 1;
      m *= dy;
      while &#40;y0 != y1&#41;
      &#123;
         y0 += dy;                           // step to next y value
         t += m;                             // add slope to x value
         PlotPixel&#40;&#40;int&#41;t,y0,r,g,b&#41;;
      &#125;
   &#125;
&#125;
//////////////////////////////////////////////////////////////////////////////////////////

// Initializes the PSP Display.
void InitializeGraphics&#40;int mode&#41;
&#123;
    sceDisplaySetMode&#40;mode,SCR_WIDTH,SCR_HEIGHT&#41;; // Sets the display mode.
    sceDisplaySetFrameBuf&#40;VRAM,BUF_WIDTH,1,1&#41;; // Sets the address of the frame buffer.
&#125;
//////////////////////////////////////////////////////////////////////////////////////////
#endif

//////////////////////////////////////////////////////////////////////////////////////////
Thanks again...
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
malaka
Posts: 3
Joined: Tue Aug 02, 2005 3:29 am

Post by malaka »

Shine wrote:
malaka wrote:- after ((64<<2)>>2) you got 0 !!!
This is wrong. Take a look at the ISO/IEC 9899:1999 C standard, chapter 6.5.7, "Bitwise shift operators":
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.

The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1*2^E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1*2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.
Oh, I always assumed the rules werent that clever.
Nice !

Anyway, if i understand well, it only decals the problems to the size of the promotion. So if you consider an "unsigned int", the promotion becomes useless and the problem does appear?
- demomacking is not a crime -
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

Does anyone have any clue as to what's wrong with my source code? I've looked at it and I can't find out what's wrong. I almost positive it's not drawing out of the buffer. Even if it went to far in the memory (into the second buffer region) it wouldn't screw up would it? Because I'm not switching buffers any, so the second half isn't being used. Any help would be appreciated.
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
remleduff
Posts: 11
Joined: Sun Jul 24, 2005 3:29 am

Post by remleduff »

My guess is that either your dy or dx end up as zero and you get a divide by zero exception in your line drawing code.

Since you're seeding the random number generator with a constant, you're always drawing the same "random" lines and it will consistantly crash after the same amount of time.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

I had thought of that devide by zero thing before, but I figured I should get an experts opinion.

I know that it's seeded with a constant, I just didn't feel like setting up something to make it random too. I can do that with intro screens that you must press a button to move on.

If it's dividing by zero, then I guess I can simply have it check for that and then change it to something different. Well, thanks for your help.

[Edit] By the way, say you get 0 divided by 1 (0/1) that wouldn't throw an error would it? It would just be '0' right? What about 0 devided by 0 (0/0), would that throw an error or would it be considered '0'?

[Edit] I thought about it, and I came to the conclusion that 'dy' cannot equal '0' or it will divide by zero. That's assuming that '0/1' is fine and doesn't throw errors. I didn't have time to really think about this or test it right now, so tell me if I'm wrong. Thanks
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
remleduff
Posts: 11
Joined: Sun Jul 24, 2005 3:29 am

Post by remleduff »

0/0 is undefined and will probably crash.

0/x where x > 0 is fine and equals 0.
Post Reply