C/C++ Programming Help Thread

[Jmaxx]

Ah, thanks.

-=Double Post Merge =-
Does oslib have it's own collision detection functions? Because I haven't been able find any tuts on it. Also, if it doesn't, are there any good collision detection tuts for regular c coding?

Because I plan on making collision based on the color that you are touching.

[Auraomega]

I'm not sure about OSLib, I never really used it. One of the most common (and easiest) methods is the Bounding Box method. Doing a Google search will probably give something better than that though. I used to have a good link for a collision detection tutorial but I can't find it anymore

-Aura

[slicer4ever]

Does oslib have it's own collision detection functions? Because I haven't been able find any tuts on it. Also, if it doesn't, are there any good collision detection tuts for regular c coding?

Because I plan on making collision based on the color that you are touching.

no oslib doesn't have an inheriantly built collision system, but it's truely not hard, just check if the boundry around 1 object is touching another, as auromega said: bounding box method, also if you want to check color's simple have an internal check as to what is what color it is and add that to your collision checking code

[basfreak]

Hi, I have another question about the PSPGU.
I have a square Vertex.
I can now display the Vertex on the screen, but is it possible to display multiple squares (the same Vertex) on the screen?
I want to make a simple grid like this:
X X X
X X X
X X X
The x' are the squares.

[Auraomega]

3 options I can see;

1. Redraw each vertex manually, shifting each of the coords by the same value.
2. Shift your drawing position then draw the same vertex, using sceGumTranslate();
3. Use a display list and set up each one manually, then you only need the draw/call the list once per loop.

Examples of all are probably available from the samples folder in the SDK, or you could check on the PSP-Programming forums again, lesson 1 covers the first and second point, lesson 11 covers the last. The last option is by far the best when you start drawing lots of images.

-Aura

[basfreak]

3 options I can see;

1. Redraw each vertex manually, shifting each of the coords by the same value.
2. Shift your drawing position then draw the same vertex, using sceGumTranslate();
3. Use a display list and set up each one manually, then you only need the draw/call the list once per loop.

Examples of all are probably available from the samples folder in the SDK, or you could check on the PSP-Programming forums again, lesson 1 covers the first and second point, lesson 11 covers the last. The last option is by far the best when you start drawing lots of images.

-Aura

Nah, I just want to make a bunch of squares like a chess board. I will check what is the best for me to do.

Thanks again:Punk:

[Auraomega]

If you're drawing a chess board, I'd definatly go with the 3rd option, because it compiles when the list is created, which means you got speed (not doing all the math each time, it just draws) and simplicity (theres no complex section in the drawing code, once you've set the list you simply call it and never look back).

The only time I've really found a display list isn't the best option is when drawing a dynamic set of images. The list is compiled which means its created once, and whatever you created is what will be drawn. Moving parts or random colours won't function properly for instance - on the other hand, you can still compile the section that doesn't move, and the section that does move, and then call the lists at different places, its basically what you do when you call vertices, although I'm pretty sure soft body physics would screw this up.

-Aura

[basfreak]

If you're drawing a chess board, I'd definatly go with the 3rd option, because it compiles when the list is created, which means you got speed (not doing all the math each time, it just draws) and simplicity (theres no complex section in the drawing code, once you've set the list you simply call it and never look back).

The only time I've really found a display list isn't the best option is when drawing a dynamic set of images. The list is compiled which means its created once, and whatever you created is what will be drawn. Moving parts or random colours won't function properly for instance - on the other hand, you can still compile the section that doesn't move, and the section that does move, and then call the lists at different places, its basically what you do when you call vertices, although I'm pretty sure soft body physics would screw this up.

-Aura

I want to make this (X = black | 0 = white | + = green):
XXXXXX0XXX
XXXX000XXX
XXXX0XXXXX
XXXX00XXXX
XXXXX+XXXX

The path (0's) will be created randomly and I want to be possible to move the + (player) along the path. Will this be possible with the 3rd method? I hope so because it sounds very easy :o

[Auraomega]

Yep; you'll simply do everything as you planned originally. All a display list is, is a compilation of vertices. You'd do something like this:

//generate all the info you need to draw the map
randomMap();

//create the list using the information from the map
createDisplayList();

//draw the scene using the display list and whatever else you need to add
drawScene();

All-in-all its pretty simple, here is the GU tutorial on display lists, you should be able to understand enough of it to work out whats going on. Here is the NeHe tutorial, with probably a better explaination of the concept, just bare in mind thats in OGL and not PSPGU.

-Aura

[basfreak]

Yep; you'll simply do everything as you planned originally. All a display list is, is a compilation of vertices. You'd do something like this:

//generate all the info you need to draw the map
randomMap();

//create the list using the information from the map
createDisplayList();

//draw the scene using the display list and whatever else you need to add
drawScene();

All-in-all its pretty simple, here is the GU tutorial on display lists, you should be able to understand enough of it to work out whats going on. Here is the NeHe tutorial, with probably a better explaination of the concept, just bare in mind thats in OGL and not PSPGU.

-Aura

Okay, will take a look at it. Thanks for all your help

Edit

Display Lists is nothing more than a cache of commands, which is important to keep in mind since once you create a display list, you cannot modify it.

So the best thing to do is create an array with the path and other squares and if a key is pressed change the array and re-configure the display list?

[Jmaxx]

How can you count to a certain number, then perform an action?

for instance

1. draw image
2. count to 3
3. delete image

[basfreak]

How can you count to a certain number, then perform an action?

for instance

1. draw image
2. count to 3
3. delete image

sceKernelDelayThread(3000 0); ?
(without space)

[Jmaxx]

I get this error when using: sceKernelDelayThread(3000 0);

error: syntax error before numeric constant

[basfreak]

I get this error when using: sceKernelDelayThread(3000 0);

error: syntax error before numeric constant

Did you remove the space: " " between the zeros?

[Jmaxx]

I didn't realize that was what you were reffering to. Why did you put it there in the first place o.o?

[basfreak]

I didn't realize that was what you were reffering to. Why did you put it there in the first place o.o?

The forum did that
I edited my message to let you know.

[Auraomega]

So the best thing to do is create an array with the path and other squares and if a key is pressed change the array and re-configure the display list?

No, I still don't think you follow. I'll take what my understanding is of what you aim to do, and we can work from there (even if I'm wrong, it'll give you a good idea of whats going on).

First thing you do is initalise everything, then you create the display list, which will contain the map you've generated, and another display for your player (if its a complex set of vertices).

Second, we call the map display list to the screen, followed by the players display list.

Third, we move the player, call the map display list to the same spot and the player display list to the new spot.

We never "re-configure" any part of the display list - ever. When you've done with that map we free the display list and create a new one, but you can't modify it on-the-fly. As I've said before, you should take a look at the OGL tutorials and work from there, they'll at least give you some base knowledge of what you're doing in 3D. You'll also get more support with OGL over PSPGU as Google will give you lots of guides/help/tutorials.

-Aura

[basfreak]

No, I still don't think you follow. I'll take what my understanding is of what you aim to do, and we can work from there (even if I'm wrong, it'll give you a good idea of whats going on).

First thing you do is initalise everything, then you create the display list, which will contain the map you've generated, and another display for your player (if its a complex set of vertices).

Second, we call the map display list to the screen, followed by the players display list.

Third, we move the player, call the map display list to the same spot and the player display list to the new spot.

We never "re-configure" any part of the display list - ever. When you've done with that map we free the display list and create a new one, but you can't modify it on-the-fly. As I've said before, you should take a look at the OGL tutorials and work from there, they'll at least give you some base knowledge of what you're doing in 3D. You'll also get more support with OGL over PSPGU as Google will give you lots of guides/help/tutorials.

-Aura

Ok, I'm trying to follow tutorials of NeHe and some from videotutorialsrock.com .
But if I now understand it right:

• initialize
• create display list for map
• ,, for player
• display map
• display player
• key pressed
• move player (display list?)
• display map
• display moved player display list

So I have to move the display list? Or should I move the Vertex.

[Auraomega]

You move the coords that the players display list gets drawn to, the player gets drawn in the exact same way the only thing that changes is the place that its drawn.

Also, I'm trying to make a backend for something, the universal method for backends seems to be:

blah --help

Blah
-o1 --option1 Option 1
-o2 --option2 Option 2
      --option3 Option 3
-h/? --help     display this message

I'm just wondering if theres also a universal way of coding the calling section, or if any old method is used?

-Aura

[Netaro]

Well, hello there, got some problems with CLUT sample.

Created two standalone functions, the initCLut and drawCLut to draw the CLUT image. It works.

Then, i moved these two functions to the Class, map it's name, and now it doesn't work at all. The graphics are all scrawny, out of sync. i double checked, the functions are LITERALLY the same, and the makefile also contains the same flags.

So, what i do now?
FIle in the attachement.

[Auraomega]

Did those working examples include using OSL? I have a feeling thats whats screwing up the code (on a quick glance). I'm going to take a more in-depth look at it and see if I can spot anything else that may cause a problem.

-Aura

[Netaro]

Both working one and the one that i posted with classes use Oslib.
I just can't see a difference 'xept the class wrap.

[Auraomega]

I'm not certain what the problem is as I can't test the code (no PSP), but the only suggest I can come up with is moving the testCLUTMap.initClut(); to inside the loop, I'm sure I read somewhere that you need to initalise the clut every time you draw if using OSL... but who knows? Just a suggestion.

-Aura

[slasher101]

I'm not certain what the problem is as I can't test the code (no PSP), but the only suggest I can come up with is moving the testCLUTMap.initClut(); to inside the loop, I'm sure I read somewhere that you need to initalise the clut every time you draw if using OSL... but who knows? Just a suggestion.

-Aura

Well you don't :ROFL:
-=Double Post Merge =-
is it possible to use VLF to primt text over the XMB?

#include <pspsdk.h>
#include <pspkernel.h>
#include <pspdebug.h>
#include <pspctrl.h>
#include <pspsuspend.h>
#include <psppower.h>
#include <pspreg.h>
#include <psprtc.h>
#include <psputils.h>
#include <pspgu.h>
#include <pspgum.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <stdarg.h>
#include <malloc.h>

#include <vlf.h>

PSP_MODULE_INFO("XMB TEST", 0, 1, 0);
PSP_MAIN_THREAD_ATTR(0);

char text1 = "test from vlf prx";
VlfText text;


int app_main(int argc, char *argv[])
{

	
	vlfGuiSystemSetup(1, 1, 1);		
	vlfGuiAddText(1,5,"tEST");
	while (1)
	{
		
		text = vlfGuiAddText(1,50, &text1);
		vlfGuiDrawFrame();
	}
	
	return 0;
}

[Netaro]

I'm not certain what the problem is as I can't test the code (no PSP), but the only suggest I can come up with is moving the testCLUTMap.initClut(); to inside the loop, I'm sure I read somewhere that you need to initalise the clut every time you draw if using OSL... but who knows? Just a suggestion.

-Aura

No, no, no, no, it doesn't work at all.

[Netaro]

http://www.megaupload.com/?d=NNVN7O6I

Yup, another problem.
It's about OSLIB's map system, but seeing what is the cause of the problem i think i'd need somebody explaining what is the difference.

The problem is, the OSLIB's map system works by passing an array to the function (oslCreateMap(itsChipset, (void*)map,16,16,30,17,OS L_MF_U16); , where map is the chipset array)
And now, the array is in the file (test.map), which has the array dimentions and the values.
I read from file, and i put it in the array.

When i use the ** array (dynamic two-dimentional) it doesn't work. Graphics are glitched (as in the already compiled file i provided).
But when i make a unsigned short array[17][30]; it works (uncomment the specified lines in map.cpp).
So, how can i make it work, as i don't think there should be any difference between two?

Also, bump as i still can't figure out the clut sample (post above).

Anybody willing to help?
So, what shall i do to make it work?

[Mr305]

Anyone familiar with both Intel & AT&T assembly?

How would you go from this Intel Assembly I believe to AT&T Gcc inline compatible?:

__asm
{
loop_copy:
instx86 128[ESI];
...more instructions
jnz loop_copy;
loop_copy_end:
}

[kuroneko]

When i use the ** array (dynamic two-dimentional) it doesn't work. Graphics are glitched (as in the already compiled file i provided).
But when i make a unsigned short array[17][30]; it works (uncomment the specified lines in map.cpp).
So, how can i make it work, as i don't think there should be any difference between two?

They are not equivalent. The latter is a 2D-array of shorts while the first is an array of pointers to some base type (short I assume).

[Netaro]

They are not equivalent. The latter is a 2D-array of shorts while the first is an array of pointers to some base type (short I assume).

Well, i provided the source code, so you don't really have to assume, it's just there.
And nope, ** can be used as 2d array, as in there -

        unsigned short ** chipsetMap = new unsigned short*[mapHeight];

	for(int i =0;i<mapHeight;i++){
		chipsetMap[i] = new unsigned short[mapWidth];
	}

And it works the same as for example, lol[y][x] and chipsetMap[y][x], but somehow it's different in the works. But i don't see it, so how can i make it work?

[yaustar]

int map::createMap(char * filename){
    
	std::fstream mapName(filename);
	
	mapName >> mapHeight >> mapWidth;

	chipsetMap = new unsigned short*[mapHeight];

	for(int i =0;i<mapHeight;i++){
		chipsetMap[i] = new unsigned short[mapWidth];
	}

	for(int y=0;y<mapHeight;y++){
		for(int x=0;x<mapWidth;x++){
			//mapName >> hex >> lol[y][x];
			mapName >> hex >> chipsetMap[y][x]; // Uncomment to check the dynamic array
		}
	}


	itsChipset = oslLoadImageFilePNG("back.png", OSL_IN_RAM, OSL_PF_8888);

	//itsMap = oslCreateMap(itsChipset,(void*)lol,16,16,30,17,OSL_MF_U16); // WORKS PARTIALLY, and that what i don't want to do.
	//itsMap = oslCreateMap(itsChipset,(void*)galaxy_map,16,16,30,17,OSL_MF_U16); // WORKS, but that's not what i want
	itsMap = oslCreateMap(itsChipset,(void*)chipsetMap,16,16,30,17,OSL_MF_U16); // DOESN'T WORK, and i want that to work

	mapName.close();
	return 1;
}

Have you checked the values of mapWidth and mapHeight when you read it from the file to see if they are correct?

Edit: I just checked the code and data and I am going to chalk it up to 'undefined error'. You are trying to read past the end of the file. The map is NOT 17 units in height but 1 yet you are trying to 17 * 30 numbers when there is only 30.