metallicafor
Unregistered
i know what u are saying but its still bit of gamble, as each revision show different behaviour. for example rev 99th could work but 100th wouldn't and i will get another 50. i supose u might have right but its still a little bit of gamble.
flashmozzg
Unregistered
(06-23-2014, 02:35 PM)AlexAltea Wrote: Given N releases, locating a regression takes at most log2(N) tests, locating the *last* regression takes at most N tests.
But located regression could be fixed in next commits. And then, reappear again (possibly for a different cause).
derpf
Unregistered
(06-23-2014, 12:48 PM)ssshadow Wrote: c01b5fb? That would be this issue then... I will reopen that issue.
Also, you didn't have to test all revisions. What you do is for example, let's say we have 100 revisions, 1,2,3... 99,100.
You test rev. 1 and confirm the game is broken. Then you test rev. 100 and confirm the game works. Then you test rev. 50. If the game works in rev. 50 you only need to look at revisions 2-49, because it had to break there, and not before it. If the game doesn't work you only need to look at revisions 51-99, again because you already know everything after 50 is also broken.
So let's say the game didn't work. You again test some revision in the middle of 51-99, like 75, and keep doing this, drastically speeding up the test process.
Just to be clear, git has a tool specifically for this:
git bisect.
Guys, I just explained how an end user can look for regressions easily by explaining the principle, and not bring up big O notation or installing git...
derpf
Unregistered
(06-24-2014, 11:30 AM)ssshadow Wrote: Guys, I just explained how an end user can look for regressions easily by explaining the principle, and not bring up big O notation or installing git...
Nobody brought up Big O notation. log2(N) is just a normal expression. And using git bisect is an example of how developers tackle this, and how anyone should if they wanted to do it.
metallicafor
Unregistered
i don't want be pain in arse but i still can't see sonic not working as issue at github - just to remind u if u forgot as u might have more important things to do.
Ekaseo
Unregistered
(06-25-2014, 09:47 AM)metallicafor Wrote: i don't want be pain in arse but i still can't see sonic not working as issue at github - just to remind u if u forgot as u might have more important things to do.
you know that if there is a regression in the emu and because of it a game wont run like it used to, chances are that more games will behave the same as this game. Its not about fixing this game, its about fixing the regression that will help other games too.
metallicafor
Unregistered
its good to know. i just want this project to progress.
i don't want be pain in arse but i still can't see sonic not working as issue at github - just to remind u if u forgot as u might have more important things to do.
metallicafor
Unregistered
i know it didnt work but we have three new errors in E
{PPU[2] Thread (Callback)[0x00e15004]} Exception: Access violation: addr = 0x1
E {PPU[235] Thread (AUTOSAVE[0x00e0f0a0]}DynamicMemoryBlock::Free(addr=0x0): failed
plus jit must be enable
this is happening when u try get in game but there is significant increase in fps in menu approx 25%
just to let u know
Dante38490
Unregistered
Good News, Now Game Save works Perfectly
http://youtu.be/mdBwu6LB8Jo
So now everything works perfectly, only remaining problem, the sounds of music crackling.
PS : This topic is moved into Playable.