Den Fri, 31 Aug 2018 18:17:51 +0100 skrev smf <smf@null.net>: > On 31/08/2018 17:28, Mia Magnusson wrote: > > It could however be implemented in Amiga emulators. Commodore but > > not 8-bit :) > > Amiga adds further complexities > > http://codetapper.com/amiga/sprite-tricks/shadow-of-the-beast/ > > http://codetapper.com/amiga/sprite-tricks/brian-the-lion/ > > http://codetapper.com/amiga/sprite-tricks/jim-power/ Oh, yes, that would need a lot of game specific work. (Tbh I almost stopped playing games before the Amiga days). > > The trouble is how to know beforehand where the screen starts/stops > > vertically. Horisontally it's more or less just to have a look at > > the modulo registers, except that you might get garbage to the left > > of the "official" screen on the first line and to the right of the > > last line, and you can't really tell where one line ends and the > > next starts so you could see some horisontal wrap in the extended > > screen area. > > modulo registers wouldn't normally change, just the bit plane > pointers. Yes, but the modulo registers is the source of how wide the actual bitmap is. > You'd only ever be able to grab out of memory what is actually > displayed, which is why you need to time travel into the future while > virtually pushing the joystick to find what data is coming up. True, by making the game view everything viewable you'd know where the limits are. > > One problem is that you won't be able to know how computer generated > > characters behave if they either have some random element to them > > or if the player interacts with them in any ways. > > They'll normally be sprites. But it'll be best guesses, you won't > ever have that much change in the character map but the changes will > look glitchy. In some cases sprites, but for example in Boulder Dash there is so much that can change that my impression is that it's only the user controlled character that's a sprite. I might be wrong. Afaik in the game logic everything is placed in a map that would work fine on a computer which only has programmable char set and no sprites or hires modes. Sprite for the main character is afaik only used to make everything else scroll smoothly when the main character moves around making the screen scroll. > Although these would likely be a problem.... > > https://www.youtube.com/watch?v=mW4w32UihGE > > https://www.youtube.com/watch?v=SiCxXMquPKs The two different depth levels? Yeah, you'd run out of data to display at the far ends. That would "only" be a cosmetic issue, or are both depth levels used by the game logic? > > I think that for a C64 or similar, you'll have to write code > > specific to every game to make it work perfectly. > > Yeah, personally I'd probably do that and get bored after one game... > > > For some games, like Scramble type games, the playable area is > > really wide, so there is a question of how much screen should be > > displayed. > > I believe the answer is, "enough to fill a 16:9 monitor". Good point, and while someone might be at it, there could aswell be modes for the rare super wide monitors (or rather TVs, intended for those who like movies as much as we like Commodore stuff). -- (\_/) Copy the bunny to your mails to help (O.o) him achieve world domination. (> <) Come join the dark side. /_|_\ We have cookies.Received on 2018-09-02 18:00:05
Archive generated by hypermail 2.2.0.