xak III: is it a fake?

Page 3/4
1 | 2 | | 4

By syn

Paragon (1920)

syn's picture

09-03-2018, 01:53

Horizontal/vertical scrolling is not hard on msx2, many people have shown that.

However creating a full game (designing /graphics/music) is timeconsuming and takes dedication/motivation, and me personally I feel I always lack either time or motivation. I think this is why ppl like to discuss about possibilities, but dont really bother to create something themselves (other than small tech demos)

Btw grauw I assumed your RPG demo during the fair was v9958, but I realize it might have been v9938. If the latter was the case, my dissapointment about the diagonal scroll not being smooth was a bit misplaced Wink

By JohnHassink

Ambassador (5413)

JohnHassink's picture

09-03-2018, 01:55

Hydragon wrote:

Hahaha maybe, I'm still "young-ish" though with my 33 years old hahaha Wink

MSX is about 35 years old and still very alive, despite the doctors declaring it officially dead multiple times. So, maybe, just maybe - we're not that old, either. Wink

By JohnHassink

Ambassador (5413)

JohnHassink's picture

09-03-2018, 02:03

@ syn: Did you abandon your arena fighter project? And yes, Grauw's thingie was impressive, graphically. It did scroll stupefyingly well for standard MSX2. I wonder about the gameplay elements and the further development.

By DarkSchneider

Paladin (869)

DarkSchneider's picture

09-03-2018, 08:29

I think the best option for MSX2 RPG SC5 is character scroll (8x8). It is not hard to get good result and the problem of the software was it did not use the parallelism, not the VDP, probably due to the PC88 original version code porting. Because that when you run it patched on Turbo-R it goes so fast (Gazzel comes already patched from factory).

By syn

Paragon (1920)

syn's picture

09-03-2018, 11:00

JohnHassink wrote:

@ syn: Did you abandon your arena fighter project?

Im focusing on something else atm, but too early in its infancy to make an announcement/newspost.

By AxelStone

Prophet (2694)

AxelStone's picture

09-03-2018, 11:27

The main problem of these mockups is that really they don't reflect the real state of a possible MSX version. The video is really fine, but I think that MSX version perhaps should be a bit more downgraded.

By Grauw

Ascended (8454)

Grauw's picture

09-03-2018, 15:05

syn wrote:

Horizontal/vertical scrolling is not hard on msx2, many people have shown that.

Btw grauw I assumed your RPG demo during the fair was v9958, but I realize it might have been v9938. If the latter was the case, my dissapointment about the diagonal scroll not being smooth was a bit misplaced Wink

Smooth horizontal scrolling on MSX2 (V9938) with 2px / frame at 60 Hz, full-screen, with sprites, is impossible. Reducing the play area to 256x160 (minus 16x16 pixels of margin) might just be able to work, but it’s extremely tight. A good way to waste a lot of time making a tech demo rather than making a game… My game in progress is for MSX2+ (V9958), because it gives breathing room to scroll at higher speeds and do things like tile animations and particle effects with sprites.

On MSX2, I would say the workable options are:

  1. 8 pixel non-smooth scroll in screen 5 / 7 / 8
  2. 1 pixel / 60 Hz frame scroll in screen 5
  3. Arbitrary speed scroll in screen 4

Each has their advantages and limitations.

By Grauw

Ascended (8454)

Grauw's picture

09-03-2018, 15:33

About why the diagonal scroll wasn’t smooth on my MSX2+ game in progress I showed at Nijmegen;

Currently I spend 50% of the CPU time on updating the full sprite colour table every frame. This is needed when all sprites change priority, and with a solid 60 fps timing budget (59659 CPU cycles/frame) I need to assume the worst case. Add to that 25% of CPU time for scrolling two pixels in one direction, and it goes just over budget when moving diagonally.

Now the CPU time spent can be optimised, e.g. time spent on scrolling can be reduced to about 10-15% I think. Since I scroll on a single page, this leaves just a small 8x212 masked strip on the side. Currently I do eight 4x16 HMMM copies every frame. Instead, I can do a single 2x256 HMMC fed straight from RAM by the CPU (270 OUTIs = 4860 cycles). Alternatively I could use 2 pages for scrolling, needing just 1-2 16x16 HMMM copies / frame, but it consumes a lot more VRAM, so I’m still undecided.

But my real grand plan to free up CPU time is to make the game run at 30 fps, while updating all the motion at 60 fps (scroll + sprite positions). This means the input handling, game logic, collision detection, tile animations, sprite animations and z-sorting, all this expensive stuff gets spread out over two display frames. This will give a lot more breathing room, and since the motion updates at a higher frequency, the game will still appear smooth.

Maybe this idea is also useful for others attempting a similar thing. I think it’s pretty nice at least. Obviously both of these changes require quite significant rewrites, so I hope it’s ok that I showed you something at Nijmegen rather than nothing Wink.

Also I’m very conscious about the time I spend on everything… Already on the current scroll code I spent significantly more effort than I planned, only to throw it away. That’s the life of a programmer I guess, but I do want to finish this, so I need to be careful to keep the scope down and make smart choices about what I work on. I have high standards and do want to impress, but at the same time need to be wary of the tech demo mentality.

(I think this was still somewhat on-topic? Smile)

By DarkSchneider

Paladin (869)

DarkSchneider's picture

09-03-2018, 15:55

Grauw wrote:

Currently I spend 50% of the CPU time on updating the full sprite colour table every frame.

But my real grand plan to free up CPU time is to make the game run at 30 fps, while updating all the motion at 60 fps (scroll + sprite positions). This means the input handling, game logic, collision detection, tile animations, sprite animations and z-sorting, all this expensive stuff gets spread out over two display frames. This will give a lot more breathing room, and since the motion updates at a higher frequency, the game will still appear smooth.

I understand you brother Sad

About the last part, you can get inconsistent frame data if the logic is for 30 fps and draw for 60, as for the 1st half drawing you may be using false data that changes on the 2nd part of the logic execution.
Or probably you are thinking about interpolation, shadow copy the last frame data, and while executing the next one interpolate that data between 2 frames.
I would target 30 fps with single page scroll. And use the resources (and time required) for other more enriching things like more animated tiles, different characters logic, etc.

By Grauw

Ascended (8454)

Grauw's picture

09-03-2018, 16:53

@DarkSchneider

To achieve the 60 fps motion, the main loop will always write two values for scroll and sprite positions, one for the current and one for the next frame. The ISR will pick the appropriate scroll position of the two, and update the sprite locations from one of two 128-byte RAM buffers. I think this is a fairly modest cost for smooth 60 fps motion.

The main loop starts right after the previous frame’s second ISR ends (let’s say at line 0), so there is some time (48336 cycles until line 212) to populate all the values necessary for the next frame. During that time quite some logic needs to happen, but the sprite colour and pattern tables are back-buffered, so I do have some flexibility there.

All the remaining time can be spent on updating the bitmap data. I only need to update the half of the 8x256 masked area that isn’t about to be scrolled in yet, so that can happen whenever. As for tile animations, I think I could also just do them whenever, and tearing won’t be very visible, but we’ll see.

Finally, you say single page scroll, why do you choose that? I’m thinking about that; advantage is that it saves a page, and if I write tile data straight from RAM with HMMC I could even avoid using another page for tile data. The remaining pages can be used for things like the conversation UI, status UI, sprite data, character animations, character portraits, fonts, etc. The downside is that the CPU spends quite a lot of time on the scroll, though sprite pattern data for animations I can update with HMMM.

However I’m also thinking maybe that’s not playing to the VDP’s strengths. If I span the scroll across two pages, with a third page for the tile set and the last page containing just UI and sprite data, the scroll update becomes really cheap. But since I won’t have room for sprite animation frames in VRAM, this will all need to be updated from the CPU.

I think these two approaches will sort of amount to the same thing, but the one may be easier to work with than the other, or allow for a bit more CPU/VDP parallelisation. Changing it later will be a lot of work, so it’s best to make up my mind sooner rather than later.

Page 3/4
1 | 2 | | 4