Started by sigh, 16:48, 23 April 12
0 Members and 1 Guest are viewing this topic.
Quote from: arnoldemu on 11:00, 08 May 12I will, these are early examples final ones will not have a repeating background.
Quote from: TFM/FS on 18:49, 08 May 12That really doesn't matter. In contrast, I think (IMHO) it's better to keep code simple, so people got a chance to understand it.I thought about releasing a kind of skeleton of my game engines scroll code too, nothing special, but since it need also a screen at &0000 it will be of no interrest to most people. But I guess in your examples it's shown how it works.Now, let's hope that some more people pick up your examples and learn how to scroll smooth ;-)
Quote from: Axelay on 12:36, 08 May 12I was interested to see what "Burning Wheels" was doing so I've had a bit of a look. The horizontal scrolling is R3 with two screens offset by one pixel, working together to produce a 1 mode 0 pixel step horizontal scroll. The vertical scroll is interesting though, it does not use R5, but uses R9 to set the character height to 4 pixels high rather than the normal 8 pixels. So now the 'course' vertical hardware scroll is 4 pixels instead of 8, and it then uses a further 2 screens that mirror the first 2 but are vertically offset by 2 pixels. So it can use this combination of 4 screens and R3 to scroll horizontally by 1 mode 0 pixel and vertically by 2 pixels.I dont see any reason why this approach should have an issue with diagonal scrolling, and slowing down an emulator I can see when moving diagonally the screen sometimes shifts both vertically and horizontally, but sometimes not, so that is why it's not smooth sometimes. I would take a guess that this is only occurring because of the way it's calculating the multi directional movement, which is not fixed to 8 directions but is a full 360 degree movement, or at least something close to it.
Quote from: arnoldemu on 19:40, 08 May 12I would like to see your "crossfire" scrolling code.Does it use rupture and split the screen into 2 sections each of which are scrolled?You then clip sprites if they cross the 2 areas?Back to the 1 pixel scrolling:I am updating the examples so you can control them with the keyboard. I will add plus scroll too for comparison and to show how it's done.After I am done showing various scrolling, I'll then move onto the scrolls used in games (push scroll etc so we can compare the merits of these).
Quote from: fano on 19:28, 08 May 12The problem is R9=0 is not compatible with CRTC 2 is my memory is good.Playing with R9 values on a character based rendering is good idea anyway.If i remember well , X-Out used R9=5 for example.A personal thought about linear addressing for lines maybe not more optimised than the actual one , it is actually faster to set or res one or two bits to reach next line than doing a 16bits addition.
Quote from: arnoldemu on 19:40, 08 May 12I would like to see your "crossfire" scrolling code.Does it use rupture and split the screen into 2 sections each of which are scrolled?You then clip sprites if they cross the 2 areas?
Quote from: fano on 19:28, 08 May 12The problem is R9=0 is not compatible with CRTC 2 is my memory is good.
Quote from: TFM/FS on 21:41, 08 May 12Using two screens of 16 KB each, in the middle of the screen they must be switched (in realtime, means at least close to one interrupt which occurs short before, but not at ys level, so it's convenient). Yes the sprite is more often divided for the two screen RAM blocks, but the transfer is easy just reset or set the two high-bytes of the V-RAM address. Yes, the start-address of both screens must be choosen wisly, but only once, then just treat both screens equal. (If you like parallax scrolling, it get's a bit nasty though).
Quote from: sigh on 13:25, 10 May 12At work and really looking forward to downloading these examples when I get home; I just can't wait to see the results!So have you finally cracked the 1 pixel multi scroll?(sorry - I don't have winape at work) How much memory does it use and what were the main difficulties?
Quote from: arnoldemu on 15:48, 10 May 12no sorry, I just added keys so it can be controlled.
Quote from: sigh on 16:33, 10 May 12Okay, cool.Quick question - How many frames per second is it scrolling?
Quote from: arnoldemu on 19:54, 10 May 1250 fps.
Quote from: sigh on 22:42, 10 May 12I managed to get the first and last example working and they look great - but I didn't manage to get the second example to run. It just stayed on the screen with all the symbols and letters even though I pressed all the keys on my laptop. (I have to hold down alt to use numberpad keys...)The last example with the plus is EXACTLY the smooth motion I'm looking for on the CPC. It's just one big drool of lovliness!!!
Quote from: Xyphoe on 23:24, 14 May 12I like that the programmer 'thought out the box' (I hate that phrase btw!) a bit
Quote from: Xyphoe on 23:24, 14 May 12Just another perhaps daft one to throw in the mix that does things a little differently is COMMANDO, it achieves very smooth 1 px scrolling vertically, but it's not scrolling the whole screen but just the background objects (eg trees, sandbags, trenches, etc) as tiles I guess. Whilst it can look a little wobbly and when there's a large section to move things can slow down (eg a bridge and tunnel, and especially later on with landing strips which are AWFUL), I like that the programmer 'thought out the box' (I hate that phrase btw!) a bit - and we ended up with a very fast and smooth playing arcade conversion that's great fun. It's nice to see something taking a different approach for scrolling, if not entirely successful. Hopefully it might throw up a few ideas.
QuoteI like that the programmer 'thought out the box' (I hate that phrase btw!) a bit
QuoteThen try using the real phrase "Thought outside of the box" but I hate that phrase too though.
Quote from: Bryce on 23:28, 14 May 12Then try using the real phrase "Thought outside of the box" but I hate that phrase too though.Bryce.
Quote from: sigh on 00:33, 18 May 12
Page created in 0.139 seconds with 49 queries.