Open LegendOfDragoon opened 9 years ago
when you say "CRC checking code" which bit of code do you exactly mean???
@death-droid https://github.com/death-droid/Rice-Video/blob/master/Device/FrameBuffer.cpp#L571
At this point, I have no clue what's going on, because I haven't spent enough time trying to understand the code. All I know is that shortening the length of the loop "fixes" this problem. I tried it in glN64 and it worked there too for some reason. If no one finds a proper solution, it might be a good idea to add an crc hack option, to make games like these, playable.
Basically, you could try something like AsmHeight / 16.
I'd actually like to understand how texture loading works. I'd appreciate any info about this :smile: .
I forgot to mention that your method of forcing textures to be the size of power of 2, causes the game to freeze on boot. Not to say the rounding code is the real problem, since it's currently creating too many textures anyway. It's just that you'll have to temporarily remove that code, in order to boot the game, unless you load a save state right after booting (not always reliable).
Hmmmmmmmmm interesting. Looking at how ever emulators handle it, Daedulus doesn't seem to even bother calculating the DRAM CRC. It just replaces textures every frame, or on the psp version it does a quick hash from the looks of it.
The asm hash from memory is just to check if the texture needs to be replaced or not or whether another already exists. We also use it for texture loading in i think? I could be way off here since I dont exactly understand what the code is doing either at the moment.
Hmmmmmmm thats odd :S, will definitely have to look into that
Current commits have a faster hash implemented at the moment (Assuming both loadhirestextures and dumptextures is off) Does it improve the general emulation of this game? @LegendOfDragoon
@death-droid I wasn't able to compile it (tried VS2010 and VS2013). After downloading the emucr build and installing 2015 Redistributable, i tested it out and it works better, but it still has issues. At the boot screen I get around 55 - 62 VI/s but am using at least 30% cpu which is more than 1 core. The menu where it's < 10 VI/s still has a big memory leak.
Ahhhh thats odd. What were the compile errors?? Might have to switch the toolset back as in ysing vs 2015 now. Hmmm interesting. Will have to look into it further
The first issue I encountered in VS 2010 was an error saying "roundf identifier not found". I guess VS2010 doesn't support roundf. After dealing with that error, I had to modify pngrw.c, because C89 doesn't let you declare variables in the middle of the scope, so you can't do for(int i = 0;;), so I declared i in the beginning of the scope. Then after that, I got > 100 errors with dxerr.cpp. The first error was "error C2065: 'D3D10_ERROR_TOO_MANY_UNIQUE_STATE_OBJECTS' : undeclared identifier"
Maybe I need the new Direct X SDK? I have DX8 and DX9 installed. Dunno about 10 or 11.
ahhh i see, weird about roundf considering i used to compile the project under Visual Studio 2010.
Ahhhhhhh was unsure how adding dxerr.cpp would effect everything. But is a necessary evil to get the project compiling fine under Visual Studio 2015. Hmmm, would be fairly easy to just use the DX9 SDK lib again if needed. The errors sound like they would be directly related to not having the Windows SDK which should come with Visual Studio 2010 and 2013 actually.
I can provide builds as well if needed, trying to improve general texture emulation at the moment
I think I have the Windows SDK. I'll see about checking my project settings then.
I can provide builds as well if needed, trying to improve general texture emulation at the moment
It would be convenient if you did provide binaries. Also I'm glad to hear you're trying to improve texture emulation. That seems to be a problem with many plugins!
The compiler errors are because I didn't install D3D10 or D3D11, I guess. I just commented out some code to get it to compile today :smile: .
Not sure what you did, but SD Hiryuu seems to run better in this latest version, although this one menu is still slow (only remaining performance issue in this game).
For one, when booting up the game, it uses a ton of RAM (like 1 gb) and takes a while to even start. Often times it actually freezes after booting up. So I think there's an issue with texture loading.
I believe there's a problem with the CRC checking code. When I shortened the loop (just to see what happens), not only were the menus running in full speed (rather than 2 VI/s), but other parts of the game also ran significantly faster. So I think the CRC detection code might be bugged. As for why the menu is really slow, for some reason, it's constantly creating new textures! This will be an interesting thing to fix, since all other HLE plugins have issues with textures in this game.
The gfx microcode used in this game is S2DEX, if I remember correctly.