Sorry for being a bad tester in the past I know that I didn't test as thoroughly as I could have done... 

Hopefully you will find someone more dedicated who will be willing to even play the most worse game all through.

The two people who applied via PM failed the "able to follow basic instructions" test.

Sorry guys

karlm wrote on 29.01.09 at 05:24:05:


you can ignore that for now...

as someone has provided me with a save game!

Shw

Heyo,

I hope I'm not intruding here, but can some of the testing be conducted through Steem or Hatari?

I'm just thinking that, ...to expand on the amount of potential testing that occurs, ...and also that a proportion of the patched games will eventually end up at some point on Steem or Hatari?

I can pretty much guarantee everything works in Steem as thats what I use for 100% of all my fixes as a base. I don't even try them on my falcon until they work in Steem.

Steem + Pasti also allows us to test with various drivers (ICDTools, HDDriver, etc).

Hatari, I'm not too bothered about - it seems to be heading down a "simulation" rather than an "emulation" route (I really hope it doesnt end up like Aranym) - If something doesnt work in Hatari its a good guess its the emulator at fault and not the patch!

As for testing, we do have a fairly large range of systems at our disposal to test on now, but I think what we need is "gameplay testing" - because it's not practical (even with trainers) for us to play things all the way to the end.  There have sometimes been weeks where we dump 3-5 titles into the test pool each day. Assuming all the titles in test actually pass, we have enough releases for one-per-day until the middle of March!

We think we have ULS at the stage now where we consider it "black box" (ie, if something doesnt work, it's NOT a problem with ULS) but as ggn pointed out we need a fairly quick turnaround on reports.

For gameplay testing, yes an ST will probably be ok. The only exception to this rule would be for titles like Terminator II, where each level is radically different and would need to also be confirmed working on the Falcon.

Yes, but I bet it detects the code and works due to a codepath rather than accurate emulation.

that == FAIL!!!

CJ wrote on 17.02.09 at 08:57:40:


I quickly looked at Hatari's C code (Why do they still code in pure C while with C++ you can produce better structured and maintainable object-oriented code? And nowadays C++ is available on nearly every platform so you don't really need C to be more portable.)

Anyway, there are functions for writes to the shifter's frequency and resolution registers. Depending on the screen location (cycle) where the write occurred and the previous state, it sets options in a bit field with line states (left border removal, right border removal, empty line/0 byte line, mid res overscan and several more.). This bit field is stored for each line which is used by the screen renderer to render the screen correctly.

Interesting read. I didn't knew there were so much options with border trickery. From the source I understand you can also make the screen smaller with 106 bytes? Which demo does that?

Robert

robert2098 wrote on 18.02.09 at 09:09:12:


Stupid me  It is of course used in hardware scrollers to get the right offset. Not to make the screen smaller.

Then thats a huge improvement, and I stand corrected.

However, until it gets a debugger as good as or better than The Boiler Room, and actually gets a user interface that doesnt make you feel like killing yourself, myself (and I suspect most others) will be sticking with steem!