BlazingFyah: IIRC official 0.9.4 has a Macintosh version. 0.9.4+ does the same emulation with 0.9.4, unless you turn on some lag reductions.
huh sorry i dont understand.. what if i were to do ur guide on windows then transfer the dsv file to mac?
and yea mien lags alot lol
http://www.youtube.com/watch?v=m_8B6pnv_7Q
theres a vid of my problem lol
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
Christmas is getting nearer and still haven’t found any gift ideas?
Don’t worry anymore, here’s the perfect present : a new DeSmuME release!
0.9.5 introduces an entirely rewritten main emulation loop
This totally changes the timing, and totally breaks old savestates.
The OSX build is now based on the GTK port which is more up-to-date.
Assorted Highlights:
synchronous SPU mode to fix streaming sounds
win32: lua engine, path configuration, 7z dearchiving support
Christmas is getting nearer and still haven’t found any gift ideas?
Don’t worry anymore, here’s the perfect present : a new DeSmuME release!
0.9.5 introduces an entirely rewritten main emulation loop
This totally changes the timing, and totally breaks old savestates.
The OSX build is now based on the GTK port which is more up-to-date.
Assorted Highlights:
synchronous SPU mode to fix streaming sounds
win32: lua engine, path configuration, 7z dearchiving support
Also, this new DeSmuME version changes a lot of things, too many to put in the changelist. But in case somebody is wondering what's changed from a TASing perspective, here are a few more highlights:
many desync fixes
better game compatibility (for example, Mega Man ZX Advent and The World Ends With You are working properly now, among others)
different timing (some things got faster and others got slower, in order to improve compatibility, but it is less laggy on average than before)
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
Figured I'd post this here, so whoever cares can relate it to the DeSmuME community: the OS X port does not appear to actually be a Universal binary, as it is not recognized by my G5 (running 10.5.8). Instead, a warning screen states: 'You can't open the application "desmume" because it is not supported on this architecture.' It may still very well run on an intel machine, but I unfortunately don't have any way to test that.
Figured I'd post this here, so whoever cares can relate it to the DeSmuME community: the OS X port does not appear to actually be a Universal binary...
There's no universal OS X binary for 0.9.5, and I'm not sure if there will be one (since it was switched to the GTK port and there's currently no Mac programmer who works on DeSmuME). You might have to run the Windows port in a VM on that setup.
OpenGL starts out faster than SoftRasterizer, but gets slower than it in a few minutes. Is there a bug?
This still happens to me with v0.9.5 :(
EDIT: And it still doesn't recognize filenames etc. with multi-byte characters.
EDIT 2: It does recognize filenames etc. with multi-byte characters. I was using an unofficial release.
Nonetheless, it is amazing!
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Joined: 8/14/2009
Posts: 4090
Location: The Netherlands
nitsuja wrote:
better game compatibility (for example, Mega Man ZX Advent and The World Ends With You are working properly now, among others)
It's probably just me, but I (still) can't get MMZXA to work with sprites.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
OpenGL starts out faster than SoftRasterizer, but gets slower than it in a few minutes. Is there a bug?
This still happens to me with v0.9.5 :(
OpenGL is faster in some places and slower in others, so it's probably not a bug. Also, it has been mostly abandoned at this point so I suggest using the SoftRasterizer.
Mothrayas wrote:
It's probably just me, but I (still) can't get MMZXA to work with sprites.
Using which version and port, specifically? I think you're probably accidentally running an older version. (EDIT: either that or your 3D settings are set to use the "None" renderer, in which case you should change it to "SoftRasterizer")
OpenGL starts out faster than SoftRasterizer, but gets slower than it in a few minutes. Is there a bug?
This still happens to me with v0.9.5 :(
OpenGL is faster in some places and slower in others, so it's probably not a bug. Also, it has been mostly abandoned at this point so I suggest using the SoftRasterizer.
I am pretty sure that this slowdown is a bug. In any place, OpenGL stays at 40-60 fps for a while, then suddenly begins to get slowing down for a couple of seconds, and finally stays at 20-30 fps (respectively). It will never get fast again until I restart the emulator.
Anyway, I've been using SoftRasterizer since 0.9.4.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
I tried to autoresync of DSM by Lua. I tried to port my Dawn of Sorrow TAS (0.9.4 timing) to 0.9.5. It failed anyway, but it synced fine for about 5 minutes. So I'm going to tell what I did. It's simple.
Run old emulator, load the game and pause emulator, load your movie (w/o unpause), and run lagrec.lua.
Start movie playback and stop Lua when movie ends. A file named "lag.db" (example of lag.db) should be output somewhere (emulator root or script root in most cases).
Remove all lag frame input from your movie by using lagtrim.lua. Run it with standalone Lua from commandline "lagtrim.lua your.dsm lag.db > nolag.dsm" or something like that.
Open dsmplay.lua with a text editor, and modify kmv_path to load the one generated by step #3 (nolag.dsm). Also, put dsmlib.lua to the same directory.
Run new emulator, load the game and pause emulator, create a new movie with pause, run dsmplay.lua, then unpause the emulator and see how it will go.
Tips:
If you cannot load a file with a relative path, write a full path instead.
If require("modulename") don't work well, use dofile("fullpath/modulename.lua") instead.
Differences between different versions of emulator aren't only just timing differences. So it sometimes fails, and sometimes successes.
v0.9.5 fails to close movie files (they are being used by DeSmuME.exe). Exploiting the fact a movie file can play beyond its end, there's a simple way to crash the emulator:
1. Play movie file A beyond its end.
2. Play movie file B.
3. Play movie file A again and DeSmuME will crash.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
I've noticed in some games, the sound zooms ahead of whatever is going on onscreen. It seems like the sound does not synch with the remaining lag that exists on the emulator.
I've noticed in some games, the sound zooms ahead of whatever is going on onscreen. It seems like the sound does not synch with the remaining lag that exists on the emulator.
You mean like in the NSMB intro? It's a known issue that certain situations still lag when they shouldn't.
I think the sound issue is just tangential. What the sound does there is probably what it would normally do if the game were to ever lag that much. Back when the world map was always lagging, the music was playing too fast there relative to the rest of the game too.
Unfortunately, it's not easy to get the timing right to eliminate this lag, because it's not clear which one of the zillion things the DS is doing that's too slow here. But maybe there could be a 0.9.5+ with a lag-reduction hack to tide people over.
Hmm, in this ninja game, i think it's too hard to read the frame counter and other information like this.
BTW, i could not control the role to move/run like in a real DS, but other actions is all ok, is there a bug?
9.5 is a joke, savestate are not stable, neither movies, i had so many desync i had to abort and resign my run, this is the first time it happen to me that bad, thx for bs release and wasting our times, it so much pissed me off ill probably never work again with desmume
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
How about being constructive for a change and reporting when it's causing a desync, with what game, etc., instead of whining like a 4 year old brat? Thx
Because it is not constructive imo to make a new release that claim to be recording movie while they obviously didnt tested making movies with it, im glad they removed lags ect... and that the main branch is improving, but next time instead of wasting our time, dont put the movie recording feature if its not tested, klmz pointed out the most obvious bug, yet, im not in the mood to track down bugs, a simple warming and recommand using instead 9.4+ (since it remove most lags, and is stable, see some run here) would have been nice
Its not like for 9.2 where everything was experimental, i would have tought an update like that would not retrograde on stability, not that much at least
Maybe somebody should hack together some unit tests using Lua so that end users don't trip over these kinds of bugs?
for rom in ListOfRomsToTest do
start recording to a movie file
generate random input for N frames, saving and reloading furiously, and checking that the memory state is deterministic...
Provide useful debug info on memory state mismatch
Just a thought.
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
Actually there were some players who was making several short runs with 0.9.5 svn wip in Japan, so it's somewhat tested before release...
Well, I think 0.9.5 is as stable as 0.9.4+ at least. There weren't so many changes which are related to sync-stability compared to 0.9.4+ IIRC. And I haven't experienced any desyncs with both versions (as you know, I'm one of DS Castlevania TASers.) So I really don't recommend people using ancient 0.9.4+.
I guess you've loaded inconsistent savestate during working anyway. It'd be better if desmume did savestate inconsistency check.
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
I fixed a few of bugs in desmume 0.9.5, so I'm going to put my updated version here.
Download improved version of DeSmuME 0.9.5
Note: It's PGOed but I didn't run the exe so much during optimization since it ran very slow on my machine (1-2 fps!), oh well
Changes
Lua: enhanced gui.overlay(). The new one can overlay a part of image and load indexed image
Maybe somebody should hack together some unit tests using Lua so that end users don't trip over these kinds of bugs?
for rom in ListOfRomsToTest do
start recording to a movie file
generate random input for N frames, saving and reloading furiously, and checking that the memory state is deterministic...
Provide useful debug info on memory state mismatch
Just a thought.
That has already been done for 0.9.5 (unlike 0.9.4), and every mismatch found in this way has already been eliminated (dozens of them).
I admit the script was not run for a huge list of ROMs, only for maybe 20 of them so far, but the DS isn't like the NES or SNES where there is a wide variety of different hardware on different ROMs, so it's unlikely that very many desyncs remain that would have been found in other games. But if anyone notices desync problems in some particular game, please let us know which game it is so that we can run the script on that game to check it out.
As gocha said here and I said in a different post on this forum, the most likely reason anyone would encounter desyncs now is because of loading the wrong savestate while in read-only mode (recording is bulletproof but playback isn't yet). And that is a problem that is not new to this version, and in fact some other emulators still have the exact same problem.
Just a question...
I compare no$gba and NeonDS, and both works faster on Castlevania games compared to Desmume.
The castlevanias don't use standard sprite engine, they rended everything on 3D engine.
Desmume works very slow for then, on frame-skip 4/5 the game gets laggy and unplayable, and values below this, the game gets too slow...
My computer specs:
Intel Dual Core 2.4+2.4 (x64 and sse supported, but running x86 windows xp sp3)
NVidia GeForce 512mb Ram
3 Gb Ram
OnBoard soundcard (Realtek)
Any hint beside "get a better computer" ?
Hmm, in this ninja game, i think it's too hard to read the frame counter and other information like this.
BTW, i could not control the role to move/run like in a real DS, but other actions is all ok, is there a bug?
