Doesn't this on C64 remember us of some demo we have on A8?

[José Pereira]

Yes, I know that for the 'similar' part at Numen is a demo but maybe...

Numen is using GR.10 same way as I said and is in 4x4 pixels so if this and then PMGs in 2x2 (half size) pixels would be the best look, I think.

Last word for coders ...

Edited April 4, 2019 by José Pereira

[emkay]

Only as it doesn't make sense to rotate that particular scene, its the same engine as post #20.

Ofcourse it makes sense to show 360 Degree rotations as the thread is about that game engine: Looking like Mario Kart and driving on the rotating ground.

 

You can't complain about that when you've not been chipping in with concrete examples of your own theories!

Not that arguing again. You AND I know I'm right there.

[Heaven/TQA]

Floor rotating texture mapper is not that hard... using it for larger map will start to become interesting though as you run into memory issues.

 

The voxel engine I have can do it with height in mode 11

Edited April 4, 2019 by Heaven/TQA

[emkay]

Floor rotating texture mapper is not that hard... using it for larger map will start to become interesting though as you run into memory issues.

The question als always is, why is such "Atari obvious" stuff always done on the worse machine for that, and not on the Atari

 

The voxel engine I have can do it with height in mode 11

Luckily the mode has that "bug" only to brighten the color channel.

[Heaven/TQA]

The question als always is, why is such "Atari obvious" stuff always done on the worse machine for that, and not on the Atari

 

 

Luckily the mode has that "bug" only to brighten the color channel.

I ment mode10 of course... or you take mode9 and are able to depths shade.

 

Look at voxel of Lynx Elements demo... same tech.

Edited April 4, 2019 by Heaven/TQA

[emkay]

I ment mode10 of course... or you take mode9 and are able to depths shade.

 

Look at voxel of Lynx Elements demo... same tech.

But depth shades also include

 

blue for water

brown for earth

green for higher regions

 

And, using some DLIs for brighter colors , would make it possible to use

 

blue for the sky

 

yellow for the sun.

 

 

and so on.

[Heaven/TQA]

I did not say its easy... thats called development in constraints of the system... on gameboy you would had only 4 colors/shades total.

[emkay]

I did not say its easy... thats called development in constraints of the system... on gameboy you would had only 4 colors/shades total.

In that case of converting Gameboy stuff to the Atari, Antic D full screen is your friend

[+MrFish]

In that case of converting Gameboy stuff to the Atari, Antic D full screen is your friend

 

Paul Lay's idea to interleave D & E is also a good solution for Gameboy stuff, since the vertical resolution for Gameboy is 144.

Interleaving reaches 144 exactly at 192 scanlines. 288 means clipping. Clipping means less processing, though; so, there's a

benefit to that too, not to mention maintaining equal pixel height.

 

But the interleaving looks good too, by adding some resolution to the display.

 

[emkay]

Paul Lay's idea ...

Paul Lay is a real genius on the Atari, but he cannot do everything at the same time, I guess.

[Wrathchild]

But the interleaving looks good too, by adding some resolution to the display.

I'd tried similar with my own experiments (Pokemon/R-Type) and overall IMO it is not as nice as leaving it in Gr.15

 

Reason being is that for a static screen in works, but something scrolling doesn't feel right.

Additionally with the static screen, s/w sprites are noticeable when they ripple due to the interleave.

 

I'd need to check with Paul but the Zelda sprite maybe using PMs as the ripple is not prevalent as it walks up/down the screen.

 

[Edit] have run the xex and see that the player is a s/w sprite.

Edited April 4, 2019 by Wrathchild

[+MrFish]

Reason being is that for a static screen in works, but something scrolling doesn't feel right.

 

I could see that being the case. Although I'd be interested to see something in action.

 

[Edit] Something to keep in mind, though, is that 3D might look different than 2D scrolling screens. So, it might be worth some testing.

 

 

Additionally with the static screen, s/w sprites are noticeable when they ripple due to the interleave.

 

I'd need to check with Paul but the Zelda sprite maybe using PMs as the ripple is not prevalent as it walks up/down the screen.

 

[Edit] have run the xex and see that the player is a s/w sprite.

 

Yes, it's a software sprite. It just seems to work in this case. The sprite is small, busy (details), and moves quickly.

Edited April 4, 2019 by MrFish

[Wrathchild]

By no means perfect, but will give you an idea of what gr.10 is capable of.

 

[+Stephen]

By no means perfect, but will give you an idea of what gr.10 is capable of.

 

That's damned impressive.

[emkay]

By no means perfect, but will give you an idea of what gr.10 is capable of.

 

As in the other video. The zoom locks f'...ng great.

But, how to get the rotations to the same framerate, at that resolution?

There still is no game engine under it.

[Wrathchild]

Rotations tend to look jerky because the calcs are based on a 192 division of the 360 degrees and a +/- 2 increment per turn and my keyboard sensitivity in the prototyping framework causes multiple turns to occur. So smoothing that isn't a concern.

 

The resolution is possibly due to utilising the UNO cart, to go native the number of calculations would have to drop significantly and so we'd end up something similar to Race7. The map I've used wouldn't make sense at that resolution and so the offer is again there that if someone cares to make one then we can preview it.

 

Your statement in regard to the game engine highlights that, yes, there is also time needed to update player positions, calculate their sprite positions and rotations to pick the images to then render. Forgive the pun but the UNO cart can lap that up.

[Heaven/TQA]

The c64 has no game engine either.

[emkay]

The c64 has no game engine either.

Nitpicking

 

The "engine" reacts to the ground, and is not just a graphical movement.

[Wrathchild]

Lunch break - have converted some other maps to 9 colours and they don't turn out bad.

(Note: they haven't been converted to the A8 palette, though should turn out close)

 

Bowser Castle

 

 

bowser.FMP

 

Ghost Valley

 

 

gvalley.FMP

 

Rainbow Road

 

 

rainbow.FMP

[emkay]

I'd still prefer something "more realistic"

Edited April 5, 2019 by emkay

[Wrathchild]

How do you define real? ... sooner or later you're going to realize, just as I did, that there's a difference between knowing the path, and walking the path

[emkay]

 

How do you define real? ... sooner or later you're going to realize, just as I did, that there's a difference between knowing the path, and walking the path

 

... to walk on the path of knowledge ... that's the only real path ...

[emkay]

This 8x4 resolution on the C64 makes every screen handling rather fast, except the fact that color ram is rather slow on the C64.

Byte boundaries allow to drop any bit calculations.

4x4 mode needs already to filter bits , resulting is a more than tiny frame dropping.

Using a similar mode could be created, using Mode F with 3 lines of re-using the same memory for LMS setting. Every 4th line won't need an LMS setting.

This would be the fastest graphics with lowest CPU usage then.

Yes, there is also the scrolling that allows to release CPU cycles.

But, for a first conversion , this would be the easiest way, as the coder doesn't need to care of screen handling-manipulations. Just import and set the 3D calculation routines and to reassign the memory locations would be the hardest work

Enough CPU for a good looking Mario on his cart would be given aswell

 

On the Atari it could be interesting to see, if coders could add all the goodies of the big color palette. Byte boundaries usually don't mean to only change the colors in byte boundaries.

[emkay]

Not to tell that , on the Atari the byte limit means to only use 8x4. It could vary between 8x1 and 8x240(239), depending on the distance and angle of view.

 

It's really unbelievable after all those decades, elementary stuff is still missing and could be done ...

if coders was taking interest.

Edited April 6, 2019 by emkay

[Irgendwer]