Kirameki could reach main menu and settings in 0.7.5 r68 (d1bcc8a)

[ghost]

I just tried some old build and found about this, Kirameki School Life SP could reach main menu and settings in 0.7.5 r68 d1bcc8a, while in r69 7b6f7ab it started crashing at the first screen when it's asked "press any button" to countinue (it's the screen immediately before the main menu).

Here is some screenshot, first r68 d1bcc8a:

Those are main menu and game settings, but when I try to start to play (the first option in main menu), it becomes black and freezes like this:

All that was in r68 d1bcc8a when it was possible to reach the main menu, at least.
This is now since r69 7b6f7ab and after:

PPSSPPWindows.exe stops working.
Log r68 4e4861a : http://pastebin.com/Gk32Mi6V (couldn't reach main menu)
Log r68 d1bcc8a : http://pastebin.com/xSWzqS49 (could reach main menu)
Log r69 7b6f7ab : http://pastebin.com/U9766ge5 (couldn't reach main menu)

All sounds and music are working, they're muted by default so you can't hear anything unless you reach the game settings and enable them manually (not possible anymore).

EDIT: updated, I hope everything is understandable.

[unknownbrackets]

Well, it looks like it's probably my fault:

d1bcc8a...7b6f7ab

But it's getting a lot of bad memory reads. Do you have a compiler? A stack trace would be helpful... it was using ReadUnchecked before, hmm...

That said, this looks psmf related as the root cause, from the log.

-[Unknown]

[ghost]

I didn't notice there were two r68 builds.

[ghost]

As compiler I'm using MS VC++ 2010 Express, today I tried to compile the zip downloaded here from github but so many errors poped that it couldn't compile anything.

[unknownbrackets]

Hmm, does it work in v0.7.5-67-g8d55445? This includes things in one 68 that aren't in the other 68.

Maybe you didn't have native.

-[Unknown]

[ghost]

in r67 8d55445 it can reach the main menu like r68 d1bcc8a, I tried 2 builds at random between v0.7.5 r00 and v0.7.5 r68 d1bcc8a all of them were working. This is the log for r67 8d55445:
http://pastebin.com/3pbVHf9V

Everything is like in v0.7.5 r68 d1bcc8a (settings work, can reach main menu and audio works too when enabled).

[unknownbrackets]

Hmm, then it should be this commit:

4e4861a

I guess it must be in the 32-bit case somewhere... probably not resizing a buffer large enough or something... hmm.

-[Unknown]

[ghost]

If there is any testing I can do to help, just tell me what you need. Although, when it comes to compiling I'm a total newbie, my first program was compiled yesterday and mostly it was a copy and paste.. xD

[ghost]

Wait a sec, if r68 d1bcc8a was submitted after r68 4e4861a then the problem started being permanent since r69 7b6f7ab and basically means:

r67 8d55445 was working, then:
r68 4e4861a wasn't, and again:
r68 d1bcc8a was working, and again:
r69 7b6f7ab wasn't

Isn't it? I'm making some hardcore confusion, now with the links should be more understandable sorry. I'll test everything once again to make sure and confirm the facts.

EDIT: confirmed 4e4861a and 7b6f7ab don't reach the main menu.

[unknownbrackets]

It's not really linear, they had a common ancestor but they were separate trees merged later on.

http://i.imgur.com/YmPKr.png

Hmm, if you want to try to get it building, just go here:
https://github.com/hrydgard/native

Download the zip, and put what's in native-master into the native/ directory in ppsspp-master. Then reopen Windows/PPSSPP.sln, it should go more smoothly.

-[Unknown]

[ghost]

This time it was able to run the debug even though it looks like this:

The ISO was loaded correctly, when it reached the "press any button" screen and I pressed X, it crashed.
This is what MS VC++ says:

Basically translated means:
Unhandled exception 0x006e4bbe in PPSSPPDebug.exe: 0xC0000005: Access violation while reading 0x08290010.

EDIT: I forgot the console:

Lol! didn't intend to close the issue! xD (wrong button).

[ghost]

New zips, new test. This time I was able to save a stack trace and some screenshot too, zipped all in this file:
http://limelinx.com/vexy

This is the first screenshot:

Console:

Stack Trace:
http://pastebin.com/hwdvhtd0

Full log file, even though it's more than 7 MB:
http://limelinx.com/xrti

[unknownbrackets]

Interesting. It'd help if you could double click on the second item in the stack trace (readIndexedTex), and show the auto or locals (variables, they're in your first screenshot but not the second.)

I'm mainly wanting to verify the value of bytesPerIndex, but also texaddr, level, bufw, and length.

-[Unknown]

[ghost]

I couldn't find a way to do it, the only thing I found is this more detailed stack trace (and a better site than pastebin) with values of the parameters:
http://paste.ofcode.org/5MTFiheTYsZa6msQu7QMVU

New screenshot:

Did it work?

By the way, if I try to continue the Debug, it spams this message:
An unhandled exception in 0x006e4bbe in PPSSPPDebug.exe: 0xC0000005: Access violation reading location of 0x083a0aa0.

[ghost]

Found it! xD

This is the full text:
http://pastebin.com/BsbFenZV

Local:

Full text:
http://pastebin.com/LkDD7Ek7

Is it possible to dump them in a file? I see there're many more lines if I open the trees, something like 100-300 lines.

[unknownbrackets]

Thanks - that's exactly what I was looking for.

Okay, so it really is a game using a 32-bit clut. That still shocks me.

I guess for the non-u8 modes (which are gonna be the most common anyway), it still needs to & 0xff. Okay.

-[Unknown]

[hrydgard]

I think the main point of 32-bit and 16-bit clut lookups is to be able to take render output and texture using one of the color channels of that indexing into a palette. Could be useful for heat vision effects and custom fog gradients.

Of course, this kind of effect won't actually work in the emu if we don't either implement palette lookups (and then we need texture filtering too) in the fragment shader, or writeback render buffers to RAM.