LaceySnr wrote:I've been meaning to post about this for ages, but I've started working on a platformer using AGT. Stalled a little recently but will try and get back into it over the next couple of weeks. It's going to be called Dave the Dragon Here's an out of date screenshot, might post a quick test build at some point (there's not much to do right now apart from jump around and shoot ineffective fireballs )
penguin wrote:Anyway, if there are any game projects, I'll be happy to cover them in my magazine.
dml wrote:Haven't tried Hatari 2.0x so can't say if that works or not.
Both use the LJBK hardscroll technique (see: 'beeshift') and therefore a 'bit' experimental. If you do get a smashed display, power cycle the ST and try another waitstate. For Steem, make sure you have chosen a real waitstate (i.e. not the default 'ignore' setting). I haven't had a lot of opportunity to test on HW so YMMV - however at least the software side is good for now.
troed wrote:dml wrote: Since Hatari does support the LJBK 4 pixel scroll this surprises me a bit. If anyone tests this on real hw please report success rate.
dml wrote:troed wrote:dml wrote: Since Hatari does support the LJBK 4 pixel scroll this surprises me a bit. If anyone tests this on real hw please report success rate.
TBH, it's easily possible I screwed something up - however It's not a 1:1 version of Paulo's synscroll. I had to modify it for overscan so maybe that has something to do with it? In any case I'll get a chance to retest later on my MegaST (it did used to work on that).
dml wrote:So I get the same result from Hatari no matter what patch state I apply to the code - or what waitstate I configure Hatari with. So I downloaded the latest snapshot, and got the same. This seems a bit suspicious - I should get different patterns of smashed bitplanes depending on WS configuration and syncscroll patching.
Playing with the code gives a bit more information - of the 4 shift offsets (0, 4, 8, 12) only 0 works properly. The other 4 produce an incorrect bitplane offset. It always seems to be the same bitplane offset for a given shift. It's very consistent.
So I tried the reference LJBK programs - beescn4 / beeshift - and they break in the same way with Hatari. Only 1 of 4 offsets works properly, in both programs.
Anyway I still can't vouch for the fixed code until I do test it properly - but it looks like 2 different things are going on here. A mistake on my part, and some problem with the LJBK sync tricks in Hatari generally. (?) I probably won't get to play with it much over the weekend but will see what happens.
npomarede wrote:But still, there was an error in the "non 4 pixel" part of the hardscroll of your demos even on my STF
dml wrote:Are you referring to these recent 2 demos or the (much) earlier ones from a year or more back? I discovered last night that the recent two are missing wakestate detect so they will configure for (I expect) WS1 always. I'll update the zips for a retest soon and maybe it will start behaving better on the same machine.
dml wrote:Other than that - it is known not to be perfect anyway - the original bee screens do break on some waitstates on some STs (i've seen occasional glitches on my MegaST also). Opening the top/bottom border on top of that *might* make matters worse - although so far on my ST it seems to be equivalent. I'm sure we'll find out more later.
dml wrote:Ok I updated the zips with the fix - hopefully this will improve matters (?)
https://www.dropbox.com/s/i049d7bxeoiw1 ... p.zip?dl=0
https://www.dropbox.com/s/5m4kferhzpoym ... d.zip?dl=0
Any more than this will need to wait until I fix my CRT.
(only the tos/prg has changed)
dml wrote:Thanks for the update. Is that after applying changes to Hatari today, or with yesterday's head revision?
And do I need to set anything specifically in hatari UI (other than WS3)
dml wrote:Ok all is clear now.
Users browsing this forum: No registered users and 4 guests