Another HARD code recovered - and expanded :) W3D...

[Irgendwer]

let me know what you could imagine to build a game out of it... (no moving sprites please).

 

Imagine a game where the player has to reach a destination as fast as possible following a path without junctions. Ranking is the elapsed time. Complexity of path is increased from level to level. I think you 'know' when the user hits a wall, so you could make them at some point 'electric', so that the player has to avoid touching them (e.g. disqualification, penalty second etc.). Change visualization to graphic 10, introduce wild colour cycles on different tiles and name that thing:

 

Psychedlic Run

 

Let me know if you need other suggestions (I have some left)...

[Heaven/TQA]

That's sound easy as a first test... Me are more into a dungeon crawler but let's see...

[Irgendwer]

Another possibility (if you can change the maze without big hassle) would be a 3D version (on an orthogonal grid?) of

 

https://www.youtube.com/watch?v=-HZS0_RW3cg

 

Even when the walls can only change in discrete distances, this could be fun.

(...a nice, matching soundtrack should of course also applied to the P.Run above.)

Edited August 16, 2015 by Irgendwer

[emkay]

Another possibility (if you can change the maze without big hassle) would be a 3D version (on an orthogonal grid?) of

 

https://www.youtube.com/watch?v=-HZS0_RW3cg

 

Even when the walls can only change in discrete distances, this could be fun.

(...a nice, matching soundtrack should of course also applied to the P.Run above.)

Actually, I like every idea that takes use of the ego 3d thingy on the A8

[Irgendwer]

Actually, I like every idea that takes use of the ego 3d thingy on the A8

 

Hopefully your mood stays, when I suggest (again) to let ANTIC mirror top to bottom to increase the frame rate while halving the calculations or double the resolution ...

[emkay]

Hopefully your mood stays, when I suggest (again) to let ANTIC mirror top to bottom to increase the frame rate while halving the calculations or double the resolution ...

Doubling the vertical resolution there, makes no sense. But using the mirroring for an even faster projection of the "3d" environment could be ...interresting

[pirx]

it will work for symmetrical textures though. no skulls man

[emkay]

it will work for symmetrical textures though. no skulls man

Seems, some things we won't get rid off. It isn't allowed to have the screen linear filled, but it should be allowed to have an inverse copy of the upper screen?

Particular rotating stuff looks odd, if the h/v ratio is to far off from 1/1 ... even 2/1 looks... not well, and 4/1 is just useless.

 

The "stretched pixels" were no fun and the screen content is allover the same resolution anyways. Particular on bigger screens "square pixels" with solid colours look better than stretched pixels with transitions. It's odd enough, when the 4/3 ratio of a standard TV set is stretched to 16/9 . That's why it's the best to have square pixels for graphics creation. which means 80x60 pixels 16 colours for such screens.

[Irgendwer]

it will work for symmetrical textures though. no skulls man

 

Like already explained in the Project M thread, there would be even a solution for non-symmetrical appearing textures: Go for graphics 10 and fiddle around with some colour registers at the horizon, and even a skull can be displayed. (Yes, colour resolution would suffer, but depending on the frame rate and available memory, this would be a saver for both resources a C64 cannot offer )

[Heaven/TQA]

the engine Tamas Bene wrote is all around optimising for 32x32 textures... non-symetrical in vertical resolution... but if you watch closely my demo... you see at some point the skull "flipped in x-direction" same with the other wall textures... I did noticed that only 1 week after having first running version with multitexture....

the source code has some "texture_mirrow" code and is doing some shortcuts in terms of table sizes (using circle/sin/cos symetries to avoid long tables). I guess NRV can tell as well something about that. the good thing about the engine is imho:

 

- is fast enough compared to speed/resolution

- collission detection

- multitexture possible (32x32, but right now only 4 max., in theory 8 possible (256 bytes div 8 = 32)

- rendering max. 64 rays but can be reduced easily to smaller render window

- relativly low RAM footprint (leaves around 12kb free)
- MPT compatible. RMT will be difficult as it nearly uses complete zeropage for speed.

 

I speeded up the code by using "mode9++" with VSCROL because Hard was not aware of that trick at that time. they normally use the "old trick" with "mode9, empty, mode 9, empty" to get that 4x4 res. they even did not use the "$0f,00,LMS,00" trick of Asskicker demos etc... so by switching to low DMA display list we gained 1 FPS.

 

btw. regarding display list DMA... don't underestimate that... I learned my lesson when coding Voxel flights that only by reducing display list complexity and DMA usage you can gain a lot CPU time back to render 1 FPS faster... that's why sometimes even 4x3 mode etc might usefull...

can you remember Planet 5200? you can put a "controll panel" under the Voxel... but when putting there Antic E lines... frame rate drops.... enable Player Missles DMA... another CPU drain... etc etc... so be carefull (I guess Koronis Rift could be little bit faster by leaving out the "Panels" but would not look good enough.) Ah...plus enabling HSCROL shift on top... again DMA time sucked from CPU.

Edited August 19, 2015 by Heaven/TQA

[emkay]

the engine Tamas Bene wrote is all around optimising for 32x32 textures... non-symetrical in vertical resolution... but if you watch closely my demo... you see at some point the skull "flipped in x-direction" same with the other wall textures... I did noticed that only 1 week after having first running version with multitexture....

So the CPU is working on texture conversions on the fly, even at that nice speed ?

 

 

I speeded up the code by using "mode9++" with VSCROL because Hard was not aware of that trick at that time. they normally use the "old trick" with "mode9, empty, mode 9, empty" to get that 4x4 res. they even did not use the "$0f,00,LMS,00" trick of Asskicker demos etc... so by switching to low DMA display list we gained 1 FPS.

 

 

And now add the good opcodes

Edited August 19, 2015 by emkay

[Heaven/TQA]

oh yes... "optimised opcodes" are not used and yet "hardcode optimisations" missing so the engine becomes still managable and readable. it is well structured and has many "JSR"s to subroutines... so you can do some inlining of subroutines.

 

re: texture mirrowing....

 

well... it's no "magic".... you have an offset running while picking the texels... so instead of say "+1" the engine replaces that with "-1"... so it remains the same codewise.

[emkay]

well... it's no "magic".... you have an offset running while picking the texels... so instead of say "+1" the engine replaces that with "-1"... so it remains the same codewise.

Well, but the "bytes" also had to be swapped for the 1st and 2nd pixel ?

[Heaven/TQA]

its only a table thing, too...

you have so called "offset tables"... which tell which texel to take... as standard procedure you have all textures in 2 formats in memory (0x and x0 nibble format, byte per pixel)… as the drawing is always same order (from left to right, you always have x0 then 0x then x0 then 0x...)

[emkay]

its only a table thing, too...

 

you have so called "offset tables"... which tell which texel to take... as standard procedure you have all textures in 2 formats in memory (0x and x0 nibble format, byte per pixel)… as the drawing is always same order (from left to right, you always have x0 then 0x then x0 then 0x...)

So they were just two different textures ?

[Heaven/TQA]

2x same textures one with x0 nibbles ($00,$10...$f0) and 0x nibbles ($00,$01... $0f)... why? because you don't know where to put each pixel in screen ram... you have 2 possibilities...as 1 byte contains 2 pixels as 4 bits define the color in mode9.

 

and to make it fast you put data on 1 page each texture row... so you adress pixels by texture_adress+u+v*256

 

that's why I can only have 4 different textures (00-$1f, $20-$3f, $40-$5f, $60-$7f).... the engine detects in the map negative values ($80-$ff) as "walkway" while values <$80 are walls.

 

map is 16x16 maze. so e.g. walls could be "20 20 20 20..." where 20 would mean take 2nd texture.