Flying on Mars surface

페이지 4/6
1 | 2 | 3 | | 5 | 6

By syn

Paragon (1973)

syn의 아바타

25-10-2017, 13:19

p.s. Nice [url=

video here[/url]… not the same technique at all but looks kinda similar Smile.

cool video Big smile i missed this when i first read this thread Wink

By Wolverine_nl

Paragon (1106)

Wolverine_nl의 아바타

25-10-2017, 14:35

that video is very cool indeed Smile

By Maggoo

Paragon (1204)

Maggoo의 아바타

25-10-2017, 15:47

ARTRAG wrote:

Thanks but I would stay with doing experiments on msx2.
I am thinking about sprite displacement line by line in the raster solution.
The current question is how many Y's can be updated within a raster line...

Anyway, if you are interested, the math for rendering is trivial, I can send you a basic source, so you can convert it to v9990

Would be interested in seeing the math :-)

About the sprites, I don't think you can change too many Y's in one raster line but if you can precalc multiple SATs and change the SAT address on the raster line then perhaps it would be doable. But is it really needed? If you don't your sprites would have the same "aspect as the background, this may not be a bad thing...


Enlighted (6443)


25-10-2017, 18:49

All depends on what is your goal. Probably a game based on tanks or on ground veicles could work.
Anyway, the lack of real 3d perspective and the flatness could impair the final result.
For now I only would like to find a way to overcome the distortion on moving objects.

The source is just few lines, if you want to see the math, look at the table named
The formula is there in the source, choose any file TOTALXXX.ASM, the data do not change

By Louthrax

Prophet (2280)

Louthrax의 아바타

25-10-2017, 19:09

Makes me think about Buck Rogers :)

By Grauw

Ascended (9334)

Grauw의 아바타

25-10-2017, 19:16

Note that you would need to cycle through just 16 SATs at most, since every 16 lines you could move to the next entry in the table. Things could also be possible to reduce it further. Good to realise there is an upper bound on the memory consumption.


Enlighted (6443)


26-10-2017, 07:36

Humm... why 16 sats?

By Grauw

Ascended (9334)

Grauw의 아바타

26-10-2017, 10:05

I think one for each display line (with sprite positions corrected by the vertical offset), and since sprites are at most 16 lines high, you can cycle back to the first one and use the next sprite index? Note that here I’m not thinking about having 1-line pattern slices, but just having the regular patterns and screen splitting their offsets in the SAT.


Enlighted (6443)


26-10-2017, 11:13

Willing to precalculate sats according to r#23, I was thinking to a different sat for each different value of r#23 on the screen.
Taking into account rounding at all, you should end with about 50 sats...
you only change the sat registers during the raster line time
you have all sprites not distorted
you allocate almost all the vram to sats
If you do not implement sorting, you need to write 50 times each change in sprite attributes


Enlighted (5595)


26-10-2017, 13:18

By updating Y you run out of time very fast... you can maybe display 2 sprites on a line... If you swap 16 SATs you are then limited to 1 sprite / line... If you need more sprites/line you need to precalc even more SATs... Maybe not one for each different r#23 value, but at least one for each line that has sprites.

페이지 4/6
1 | 2 | 3 | | 5 | 6