forums.ps2dev.org

Ghoti wrote:yes i know (ashamed)
but thank you also for sticking to the thread and helping me!! I really am glad that this strange bug is over :)))

thanks again

Yes .. not so strange after Tyranid's explanations :)

++

Ghoti wrote:one of my classes opened a file but did not close it. Now it is closed and it does not crash anymore !!! :D

... The next time when it is asked to check ... please check :p

Ghoti wrote:that also does not work :(

I will check the paths and stuff again :s

Yes check check check ... i don't see any other solution ... :(

ok ! great ! :)

Thanks for your patience and explanations :)

i can't wait for your releases ! ;) soon ? :)

instead of :
try


declare your FILE ressource like this everywhere :)

the only way of keep THIS file opened is to forget to close it ... is this file is opened before in your code ?

The psp doesn't open files itself "for fun" :Ptry maybe to recreate your race file .... copy/paste his content to a new file.

charnold wrote:I havn't used external tools for this (I'm generating the lightmaps in my prog.). Don't some editors have integrated lightmap creation?

ho ok ... i thought that the "LMP" file was generated by a third party software :)

You have a good link for a lightmap calculation tutorial ? :)

does the same with a file at the root of the MS ? ...

seems very very strange ... hard reset your psp :D

very strange ... can you get the strlen of sBuffer and be sure that there is no '\n' or something else ? maybe there is a blank space before or after you "real" sBuffer ... the fopen method seems to be called perfectly ... so if you're sure that the file is at the correct place and sBuffer...

try to break your code into small parts and checks each part l.. part by part.. displaying some variable status etc... ... and put some pspdebugprintf to display the debug on the PSP and for reading files ... sscanf(ReadBuffer,"y=%d",&y); should be better (for example)....

Why do you add "2" on the readbuffer ? ...

Your code looks strange for me :P

hummm can we have an example of your race file ?...

it seems that your format version take 7 lines !!??!! (fgets stops when a '\n' is found)

... why don't you do a

while(fgets(....))
{
//parsing with sscanf ...
...
}

?

have you tried to remove the blank space in the race name .... (and change it everywhere according to it) ?
...

Without psplink .. you're putting your file where is the eboot ?

maybe a silly question .. but psplink read from your computer directory ... and the standalone EBOOT from your MS ... :) (if you work with a relative path)

you can render lightmaps like this: 1. pass (normal texture) with sceGuDepthFunc(GU_GEQUAL); sceGuDepthMask(GU_FALSE); sceGuDisable(GU_BLEND); 2. pass (same poly, lightmap texture) sceGuDepthFunc(GU_EQUAL); // only pixels with same depth pass the test sceGuDepthMask(GU_TRUE); // no depth buffer wri...

yes i will post a screenshot as soon as i get back to home :)

thanks !

the palette/texture format shouldn't have any influence on the depth. but the topology and position of your mesh does. btw. some games use just per-vertex colors instead of lightmaps, sometimes that's sufficient and you can render it in one pass. Humm what do you mean by "topology" ? i'm ...

ufoz wrote:use sceGuDepthOffset to get rid of z-fighting maybe?

It may be a solution ... (thanks for all these hints ! :)

:)

rapso wrote:you need to use exactly the same positions and topology in both passes to get it working. otherwise there will be allways z-fighting.

same geometry positions ? and same palette/texture format ? and it must work ?

ok i will try that :)

thanks :)

Hello ! :) It seems that that the only way to manage lightmaps is to use multiple passes. So .. when i render (for example) a wall with the wall texture and the second time with the lightmap texture (+alpha blending) ... everything is blinking (i think coplanar triangles make the GPU to be confused ...