forums.ps2dev.org

Sounds like you should try to separate the two. Maybe update the intraFont in OSLib and then quit using it separate from that. Seriously, this is why I hate C++. Even when you know what you're doing, it's a royal pain in the ass. I never write any on my own stuff in C++, and dislike working on C++ p...

Well, post some example code and maybe people will use it. :)

That last post made no sense at all. :)

Don't try to turn intraFont into C++ if you don't know what you're doing in C++ (that's the errors in your first post - ignorance of C++ errors). Leave it as C and make sure it has those extern "C" {} in the h file.

jojojoris wrote:Why don't we use the normal network dialog from the firmware to establish the connection? In my opinion that would be far more user friendly and it looks more professional.

Because no one knows how to do that. :)

What I meant was the functions themselves have changed - in name, function, etc, over time. You may be trying to use an "old" function that was eliminated or changed. Go through YOUR code and change it to use intraFont as it is NOW, not how it was X revisions ago.

1.50-based homebrew can only use WEP encryption. To use WPA, you have to switch to 3.xx based homebrew.

Also, the network connections list the PSP maintains seems really fragile. I've had to go delete all connections and remake them a number of times.

Check which version of intraFont you're using... there have been BIG changes to intraFont that required changes to programs using intraFont.

Nine_Masquerade_ wrote:Basically what I am asking is can main.c be passed as a parameter and then used in methods inside of other objects?

No. You need to go review your C++ a bit. Remember that C++ is the same on the PSP as on any other platform. If you can/can't do it on a PC, you can/can't do it on the PSP.

Maybe its only required if it hangs during the connection procedure. But from all the network sample and homebrew source I've seen I don't think anyone has bothered to handle the error if it craps out in the connect to AP function while the states are changing :P Yeah, it's just if it doesn't finis...

You might look at the network init code I used in Basilisk II. There were issues with how some people were retrying on the network connect that I fixed. sounds like a cool project, did you port it (cause I've found non-psp version) or is this from scratch by yourself? Just a port. Lots of folks hav...

So they've identified more of the states, huh? :) I'll have to update my own stuff some time.

You might look at the network init code I used in Basilisk II. There were issues with how some people were retrying on the network connect that I fixed.

Dariusc123456 wrote:Is there away to avoid memory leakage?

Keep better track of your memory. :)

If it works on an x86 CPU based PC, then it won't be an endian problem on the PSP since they are both little endian.

Set up the proper matrices, then use sceGumDrawArray instead of sceGuDrawArray. Look at the sprites sample.

The blit gu sample does slices. Slices are for two reasons: speed (makes better use of the texture cache), and size (anything bigger than 512 can't be done in one operation regardless of speed).

You STILL haven't mentioned what the source of the data is - what format it's supposed to be in, nor what machine it is produced on. Without the info, there's no way to know how the data should be parsed by the PSP.

Look at the ubiquitous graphics.c. Look at any program that draws using the GU. Look at nearly every gu sample in the sdk. The samples are there for a reason.

You'll see in many examples and apps that wide textures are drawn in "slices". The reason is the PSP uses a texture cache that can only hold so much data - if you go too wide on the texture, the cache is reloaded (maybe more than once) on every single line drawn. If you cut a wide texture ...

You should probably consult the Lua docs. That's better than just asking randomly at sites not dedicated to Lua.

Oh, yeah - I keep forgetting you need to put those two switches together. :)

Add -S to the CFLAGS in the makefile and make one of the simple examples that come with the SDK. That will generate assembly files for everything. That's the best way to figure all that out.

You misunderstand - I'm the NICE one. You don't want to see the response you get from asking things like "what's the difference between makefiles and batch files?" for some of the people here. I simply told you to go learn some basic skills first. Your parentage, ancestry, and mating habit...

shdi_us wrote:is a make file similar to a batch file?

No, now go away and learn to use gcc before coming back. We don't give basic lessons on programming here. There are literally THOUSANDS of other sites the DO give basic lessons.

rapso wrote:(I really miss the console feeling tho)

The problem is that modern "consoles" aren't consoles anymore - they're compact computers. Just as you wouldn't try to write a PC ethernet driver that ignored memory mapping, PS3 drivers shouldn't ignore memory mapping as well.

I'd try google for that. It's not a PSP problem, it's a game engine problem and probably has a variety of "solutions". So use google to find a few and see what works for you.

Enter them into the shell directly before you try to run the script.

Don't forget to export the environment variables. export PSPDEV="/usr/local/pspdev" export PSPSDK="$PSPDEV/psp/sdk" export PSPPATH="$PSPDEV/bin:$PSPDEV/psp/bin:$PSPSDK/bin" export PATH="$PATH:$PSPPATH" export PKG_CONFIG_PATH="$PSPD...

http://www.guztech.nl/index.php?view=ca ... &Itemid=56

If you have a good toolchain, you can skip to step 4.

You can find the MediaEnginePRX and demo code in the arc linked in this post:
http://forums.ps2dev.org/viewtopic.php?p=82591#82591

That shows how to make and use a kernel level prx.