XRacing (MSXDev 2018 entry)

Page 11/13
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13

By NYYRIKKI

Enlighted (5382)

NYYRIKKI's picture

22-02-2019, 17:15

santiontanon wrote:

@NYYRIKKI: Nice!!! It indeed looks much better! And indeed you are right. The Clustering algorithm I use does not take that into account! Another thing that it does not take into account is how often a tile appears (to make sure that tiles that appear more often on the screen are represented more faithfully). I wanted to at least add that, but didn't have the bandwidth to get it done for the deadline.

Actually during testing I found much more easy "algorithm" to fix this... When ever there is "loose pixel" on top row, bottom row, left column or right column, you just remove it... What I mean in this case by "loose pixel" is not individual separated from others, but a pixel that is not on a up/down or left/right line with other nearby pixels... I mean kind of "off by one" compared to others.

This is also kind of easy to justify (although I suck @ explaining). Because of the square shapes the "turns" that colors need to take are either small or about 90°. There is no practically any need for 45°turns, so when the shape continues from another character it continues most likely either from line that most of the pixels were or from same place where the "loose pixel" was. If not, it is anyway sure that in this case it must be on "fast moving" part of the picture. If it continues from the "loose pixel" position while the pixel was removed the correct change place will be shifted by a pixel. When the back/white shapes are this big, this 1 pixel error on a not straight line is almost impossible to notice. How ever if the shape continues from "most pixels" position and the "loose pixel" is not removed it causes this jitter/zig-zag on a other ways straight line, that is very easy to spot and looks nasty.

This rule seems to work so well, that I must say I wonder if it should be applied in case of "two loose pixels next to each other" as well though I did not test this. I think this would make great number of characters just straight lines from up to down or left to right and force movements more strictly to between of characters, but as there would be still some variation that might keep illusion of more free movement. This might also further reduce the number of needed characters... I don't really expect this to work well, but I would say there is definitely space for some further experiments.

By santiontanon

Paladin (833)

santiontanon's picture

22-02-2019, 22:27

Very interesting!!! and I think I understand, so your explanation was clear enough Big smile

I actually wanted to separate the code that I use for generating the flag animation and make it stand-alone, in case other people want to use to include these flag-style animations in their games (it should work for other animation loops that are not just a flag). So, all these ideas you list are very cool, and will play around with them!

I don't think I'll have time this weekend (some deadlines on Monday), but I will start playing around with this next week.

By ARTRAG

Enlighted (6243)

ARTRAG's picture

24-02-2019, 17:03

Santi, for your fun I've loaded source and roms of two scrolling demos showing how to use the two pages of 256 tiles each (based the graphic from xracing).
https://github.com/artrag/scroll_8_ways/
The second rom now is using the two pages for double buffering in screen 2.

By santiontanon

Paladin (833)

santiontanon's picture

24-02-2019, 22:08

Oh wow!! The 128KB one is very impressive!!! I haven't had a chance to look into the details of it! Definitively on my list, because if this works as I think it works, combining your technique with the "rails" idea of XRacing, the graphic variety of the maps can be increased significantly!

By Wlcracks

Champion (325)

Wlcracks's picture

25-02-2019, 17:29

@ARTRAG
Thanks for sharing.
First one works fine in openmsx even in 60hz MSX1
Second 128k gives an warning: "Too fast VRAM access PC=0x4068 Y-pos=1" on an 60hz MSX1 and
"warning: Too fast VRAM access PC=0x406a Y-pos=3" on a 50hz MSX1

I'v tested the 128k version on a real msx1 but seems to work fine though. At least same as on openmsx in msx2 mode. Its not full screen?

By ARTRAG

Enlighted (6243)

ARTRAG's picture

25-02-2019, 19:04

The scrolling is on 2 banks out of 3 in order to get two pages and to avoid issues on sprites
About the fast write, in the way it is, it should not affect the real machines, anyway sources are included, fix it as you like

By ARTRAG

Enlighted (6243)

ARTRAG's picture

26-02-2019, 09:10

I have added a draft split screen to allow screen 1 graphics on the top third of the screen
For now on the 48KB rom

By hamlet

Scribe (2528)

hamlet's picture

26-02-2019, 11:09

Very cool ARTRAG!

By wimpie3

Champion (259)

wimpie3's picture

26-02-2019, 12:23

Nice!

By Wlcracks

Champion (325)

Wlcracks's picture

26-02-2019, 15:03

ok can somebody please explane whats going on here?
Since when is it possible to get scan-line number on msx1??

1:  in  a,(0x99)	; wait raster line
    and %01011111
    cp  %01000100	; plane 4 =0x44
    jp  nz,1b
Page 11/13
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13