Optimizing Wolf3D-style rendering

[hammer]

Originally Posted by pipper

Quake can run on a 486. I played it on an AMD 486DX4-120. Not the fastest thing in the world but playable.

Quake was released in 1996 and I brought my 1st PC Pentium 150 and S3 Trio 64UV in the same year. Quake and Flight Unlimited was the trigger fully switch to PC when Phase 5 has ripoff prices for Cyberstorm 68060 and Cybergraphics 64 combo for my Amiga 3000. I overclocked Pentium 150 to Pentium 166 MHz with simple 60 MHz to 66 MHz FSB jumper.

Pentium 200 and Pentium Pro 200 MHz was the flagship SKUs along with 3DFX Voodoo 3D accelerator.

Phase 5' 68060 + Cybergraphics 64 + Amiga 4000/030 wasn't price competitive at 1996 time period. Amiga 4000 wasn't built as lower cost mini-tower with a single micro-ATX size motherboard.

In modern times, PC has Microsoft Flight Simulator 2020 and just bought out Bethesda's parent company, hence keeping critical PC games on the PC. Sony poked the bear enough and the bear counter attacks (using it's massive cash reserve).

At least Apollo team targeted Amiga 500 price range for Vampire V4 despite the +5000 units. Amiga Technologies and Motorola couldn't deliver preformance upgraded A500/A1200 replacement.

[britelite]

Not much happening here, but let's still leave off-topic crap out of this thread

[mateusz_s]

Originally Posted by britelite

Not much happening here, but let's still leave off-topic crap out of this thread

Hi @britelite,
are you still on that topic?
I saw that you been making some stuff using mode7 I guess?

Can it be used to generate floor in raycaster, for example adding a floor to that wolf3d you worked. I am asking because, I am working for some time on my own raycaster engine under RTG and 32 bit.. I have highly optimed the walls rendring with shading, but floors/ceilings are very cpu expensive to calculate.. I tried many different algorithms, like: horizontal and veritcal scanline approach, also tried to make a triangles from cells and rasterize them. But always the cpu calculations are too high.

I think the main problem is, that I can use different texture per floor cell - with only one texture the calculations are much faster.

I wonder - if I could use mode7 technique to render faster that tiled floor? But I am not sure.
The examples of mode7 are always operating on single texture. For example in my case - in single room my floor can be made of ex. 8 single square textures. Or maybe render every single floor cell in mode7 technique - but I don't know if that possible too - the mode7 examples looks like they fill the whole screen to infinity..

[britelite]

Originally Posted by mateusz_s

Can it be used to generate floor in raycaster, for example adding a floor to that wolf3d you worked.

The routine I've been toying around with wouldn't work with my wolf3d raycaster, as it wouldn't sync up with the walls (as it's not really moving in the same space).

The examples of mode7 are always operating on single texture.

Yeah, my approach also only uses one (large) texture, so it might not really be suitable for your needs.

[ImmortalA1000]

Any new updates on Wolf3D?

[rothers]

Didn't Dread have a Wolfenstein demo? Runs full speed on the A500 I think. There is also:
[ Show youtube player ]

[hammer]

Originally Posted by rothers

Didn't Dread have a Wolfenstein demo? Runs full speed on the A500 I think. There is also:
[ Show youtube player ]

Commodore's official position on "pack pixels" is Akikio C2P solution which locked out A1200.

https://bigbookofamigahardware.com/b...t.aspx?id=1604

The “chunky to planar” logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch” of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch!

Commodore officially locked out the A1200 from these types of games. Optimized Blitter assists C2P source code wasn't part of Commodore's SDK.

[Bruce Abbott]

Originally Posted by hammer

Commodore's official position on "pack pixels" is Akikio C2P solution which locked out A1200.

No, it didn't. All you needed for 'official' support on the A1200 was 3.1 ROMs.

Commodore officially locked out the A1200 from these types of games. Optimized Blitter assists C2P source code wasn't part of Commodore's SDK.

Commodore didn't have this 'Optimized Blitter assists C2P source code' you speak of. I doubt they even considered the idea. However they did put their c2p code in the 3.1 ROM for anyone to use, and provided the ability to use hardware c2p devices too.

But let's say Commodore did give us 'Optimized Blitter assists' c2p source code better than anything we could make ourselves. That would spoil the fun! So I'm glad they didn't. I'm also glad that they didn't put a chunky mode in the A1200, because that would be even more boring.

[hammer]

Originally Posted by Bruce Abbott

No, it didn't. All you needed for 'official' support on the A1200 was 3.1 ROMs.

Wrong. ROM's new functions need to be on the official SDK documentation.

Releasing ROMs without matching official SDK documentation is crazy.

Originally Posted by Bruce Abbott

Commodore didn't have this 'Optimized Blitter assists C2P source code' you speak of. I doubt they even considered the idea.

Based on Commodore's Ken Dyke (software) advice, Commodore pushed Akiko C2P direction. CD1200 had the Akiko chip with FPGA fooling other functions.

Originally Posted by Bruce Abbott

However they did put their c2p code in the 3.1 ROM for anyone to use,

Was it "optimized Blitter assists C2P"?

Originally Posted by Bruce Abbott

and provided the ability to use hardware c2p devices too.

Useless for the higher unit sales A1200.

Originally Posted by Bruce Abbott

But let's say Commodore did give us 'Optimized Blitter assists' c2p source code better than anything we could make ourselves. That would spoil the fun! So I'm glad they didn't. I'm also glad that they didn't put a chunky mode in the A1200, because that would be even more boring.

[Old_Bob]

Originally Posted by hammer

The “chunky to planar” logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch” of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch!

Interesting to read, this. As well as being more than a bit infuriating.

If I was present, I'd certainly suggest that some kind of blitter-like functionality would be preferred. With a bunch of pointer registers for each bitplane, along with maybe a modulo value for each and a BLTSIZE type register to set the thing in motion with no further intervention from the CPU being needed from that point.

I guess that might be a much more complicated thing to design, but presumably within the limits of the possible for these people to create?

B

[Samurai_Crow]

Re:blitter based C2P
It's been done but not in time. Grind and the engine it's based on use blitter for chunky to planar conversion. On an A500 it gets playable frame rates at a low resolution.

[AestheticDebris]

Originally Posted by Old_Bob

Interesting to read, this. As well as being more than a bit infuriating.

If I was present, I'd certainly suggest that some kind of blitter-like functionality would be preferred. With a bunch of pointer registers for each bitplane, along with maybe a modulo value for each and a BLTSIZE type register to set the thing in motion with no further intervention from the CPU being needed from that point.

I guess that might be a much more complicated thing to design, but presumably within the limits of the possible for these people to create?

B

I assume the engineers were looking at it more as "what can we add to solve the problem without altering any of the existing chipset" - if it couldn't fit inside the spare space in Akiko, they weren't going to be able to deliver it

[Bruce Abbott]

Originally Posted by hammer

Wrong. ROM's new functions need to be on the official SDK documentation.

It was, obviously. What makes you think it wasn't?

For your convenience, the autodoc for the new V40 WriteChunkyPixels
function is attached below.  All CD32 developers should have the full
V40 OS for their development machine, and V40 autodocs, includes,
libs, and fd's.  Archives of the V40 Workbench disks, V40 kickfiles,
and V40 development files may be downloaded from our closed
developer conferences on BIX (US), ADSP (Europe), and CIX (UK).

graphics.library/WriteChunkyPixels         graphics.library/WriteChunkyPixels

   NAME
	WriteChunkyPixels -- write the pen number value of a rectangular array
	of pixels starting at a specified x,y location and continuing
	through to another x,y location within a certain RastPort. (V40)

   SYNOPSIS
	WriteChunkyPixels(rp,xstart,ystart,xstop,ystop,array,bytesperrow)
	                  A0 D0     D1     D2    D3    A2     D4

	VOID WriteChunkyPixels(struct  RastPort *, LONG, LONG,
	     LONG, LONG, UBYTE *, LONG);

   FUNCTION
	For each pixel in a rectangular region, decode the pen number selector
	from a linear array of pen numbers into the bit-planes used to describe
	a particular rastport.

   INPUTS
	rp     -  pointer to a RastPort structure
	(xstart,ystart) -  starting point in the RastPort
	(xstop,ystop)   -  stopping point in the RastPort
	array  - pointer to an array of UBYTEs from which to fetch the
	         pixel data.
	bytesperrow - The number of bytes per row in the source array.
		This should be at least as large as the number of pixels
		being written per line.

   RESULT

   NOTE
	xstop must be >= xstart
	ystop must be >= ystart
	The source array can be in fast RAM.

   ===chunky-to-planar conversion HW:

   GfxBase->ChunkyToPlanarPtr is either NULL, or a pointer to a HW
   register used to aid in the process of converting 8-bit chunky 
   pixel data into the bit-plane format used by the Amiga custom
   display chips. If NULL, then such hardware is not present.

   If an expansion device provides hardware which operates compatibly,
   than it can install the HW address into this pointer at boot time,
   and the system will use it.

   This pointer may be used for direct access to the chunky-to-planar
   conversion HW, if more is desired than the straight chunky-pixel
   copy that is performed by WriteChunkyPixels().

   If using the hardware directly, it should only be accessed when
   the task using it has control of the blitter (via OwnBlitter()),
   since this is the locking used to arbitrate usage of this device.

   The hardware may be viewed as a device which accepts 32 8-bit
   chunky pixels and outputs 8 longwords of bitplane data.

   For proper operation, exactly 8 longwords (containing 32 pixels)
   of chunky data should be written to *(GfxBase->ChunkyToPlanarPtr).
   After the data is written, bitplane data (starting with plane 0)
   can be read back a longword at a time. There is no need to read
   back all 8 longwords if the high-order bitplanes are not needed.

   Since WriteChunkyPixels is not (currently) particularly fast on 
   systems without the chunky-to-planar hardware, time critical
   applications (games, etc) may want to use their own custom conversion
   routine if GfxBase->ChunkyToPlanarPtr is NULL, and call
   WriteChunkyPixels() otherwise.

   This pointer is only present in GfxBase in versions of graphics.library
   >= 40, so this should be checked before the pointer is read.

Releasing ROMs without matching official SDK documentation is crazy.

So it's good thing that didn't happen, right?

Was it "optimized Blitter assists C2P"?

Can't you read?

Useless for the higher unit sales A1200.

I disagree. c2p hardware could easily have been included in RAM boards and accelerator cards. A c2p chip that ran at the speed of the accelerator card CPU would be faster than Akiko. So why didn't anyone make such a thing? Because for most Amiga fans it wasn't as much of a big deal as people like you make out.

[Karlos]

Adding C2P hardware to a ram card would be pointless unless it was a direct register/address compatible replacement for akikio as nothing would use it otherwise.

Akiko is not an ideal C2P anyway. If it lacks one thing that could have really helped, it's the ability to write to chip memory itself: start of each frame, set your base plane pointers (or just one and a stride value if you assume planes are allocated contiguously) and just keep smashing your chunky pixels at it while it knocks the planar data out the back door, incrementing the pointers as it goes. That would've been nice.

[hooverphonique]

Originally Posted by Karlos

Akiko is not an ideal C2P anyway. If it lacks one thing that could have really helped, it's the ability to write to chip memory itself: start of each frame, set your base plane pointers (or just one and a stride value if you assume planes are allocated contiguously) and just keep smashing your chunky pixels at it while it knocks the planar data out the back door, incrementing the pointers as it goes. That would've been nice.

I was thinking exactly that when reading further up in this thread, actually. It wouldn't require dma, but "just" chipram writes, similar to what the cpu does.

[Karlos]

Back on topic, what's the latest with the raycaster?

[Photon]

I agree with all points by Bruce Abbott, except the last one - a chunky mode to spoil the fun would have been great with the improved DMA speeds of A1200. I even called up a Commodore-Amiga representative to tell him so back in the day - before AGA. Ah, the innocence of youth.

I also agree with Karlos, to get back on topic, which is: the Amiga didn't get a HW chunky mode. It's a fact. Now, how can the Amiga do even greater things?