@NutsAboutAmiga

True, but that wasn't really what I was thinking about. In this case, it's more like a use case involving dividing a bunch of integer numbers by N. Faster to make 1/N in a floating point register and multiply the numbers (with conversion from int to float and back) by this because floating point multiplication is faster than integer division.

_________________
Doing stupid things for fun...

For anyone playing the KarlosTKG mod, I've pushed a number of changes and improvements:
* Water dead-end trap in Level C fixed
* Some texturing bugs in Level A fixed
* Green Ashnarg (the beholder thing with arms) no longer spawns enemies on death as they can't be targeted and in some cases are invisible. Invisible, untargetable enemies charging you isn't exactly fair. Don't get too close though, like his red slightly harder brother, his guts are corrosive.
* Assimilated marines are faster, but no less annoying.
* By popular demand the experimental loop based music has been replaced with the original (slightly modified) bass pulse.
* Power Plasma bolt is now faster but takes time to reload.

_________________
Doing stupid things for fun...

New video https://youtu.be/JH6HYQ49604

* Fixed floor texture drifting
* Original music (almost, see if anyone noticed what changed)

Some improvements to this particular level.

_________________
Doing stupid things for fun...

@Karlos

Love the dark mood of the game!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Karlos

Sorry stupid question, but what file I need from here https://github.com/mheyer32/alienbreed3d2

@utri007

Not a stupid question, but a bit of a slippery answer.

The repository there is for pipper's updated engine build which is moving towards being more system friendly. You don't technically need it if you have the original game executable.

This version of the executable is still very much in development and has various issues. There's no build/release cycle for it yet, so if you want to use it, your only choice right now is to checkout the repository, follow the readme and compile it yourself*.

Once you have an execuable, you need the game data files. Thankfully, this is easier if you just want to play the version in the video. You'll need my mod, here: https://github.com/0xABADCAFE/karlos-tkg which contains all the files needed.

All you need to do is download the repo (you can get it as a zip straight from github if you like) and put somewhere accessible from your Amiga (or emulation).

The repo contains a Game directory, which is where the KarlosTKG launcher is (see: https://github.com/0xABADCAFE/karlos-tkg/blob/main/Game/KarlosTKG). This sets up the stack and assigns and at the end runs the executable. Put your executable in the Game directory and make sure the KarlosTKG launcher script is set to execute it.

Double click and you're away**.

* Versions have been uploaded on EAB. See: https://eab.abime.net/showthread.php?t=111090
** You may not be away. Away may be redefined as a guru code. Terms and conditions apply.

Last edited by Karlos on 27-Aug-2022 at 01:07 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

There's no question that putting a 603 into my A1200 allowed me to do things that where impractical on the 040, and only became more obvious after I added the BVPPC on top. As a hobby coder there was lots fun to be had. Optimising code for minimum context switching under 3.x/WarpOS and PowerUp was also an interesting challenge.

That would go above and beyond the usual use case of JPEG loading. And yes a friend today said that was his main use of PPC. I think it's easy to forget these days after we integrate modern machines in our life but simple things like loading a JPEG needed a lot of CPU power for a slower Amiga.

I had a chance to buy a BlizzardPPC I add to my Amiga regrets. It was on special for AU$800 locally. But I only had a desktop and it really needed a tower. It was less than double what I paid for my Cobra 68030 @40Mhz, $450, and worth it for the 68040 and PPC combined.

Quote:

OS4 is "ok" on the machine, but there's no doubting that it's intended for faster hardware. The PIO IDE interface hampers it. Ironically I have the SCSI controller but no hardware for it. I did start a driver project but without real HW and time, it withered on the vine.

I recall OS4 supported some SCSI controller but didn't support an obvious one and I didn't know why. They had the OS source. And if not there was usually Linux driver so there were open sources generally available.

But yes, OS4 is better on dedicated boards. Well, the faster boards. I've seen OS4 run on the real thing and also have an emulated OS4 setup. They may have coded OS4 on the real thing but it was obvious it was a bridge to faster hardware. Seeing OS4 on an Amiga compared to even my XE and now my X1000 is worlds apart. People make comments that they could emulate OS4 on WinUAE for a cheaper X5000 experience, but, no they can't. QEMU, that's closer to the mark, but speed isn't there yet.

Quote:

It runs 68K Doom (DoomAttack020+) at 640*400 though, so there is that. If TKG runs, it would be interesting to see how well.

It would kill at that.

Quote:

Regarding RTG, I'm definitely interested to see if I can bypass the whole colour reduction and see if 24-bit RGB is doable. Or at least 16 bit, if data transfer is an issue.

I don't know but it could be possible, given the age, that the graphics are 8 bit. Even so. rendering 8 bit images into a 24 bit framebuffer would still benefit, since it wouldn't need to remap colours. But, in that case, it could use a shared palette.

@Karlos

Quote:

True, but that wasn't really what I was thinking about. In this case, it's more like a use case involving dividing a bunch of integer numbers by N. Faster to make 1/N in a floating point register and multiply the numbers (with conversion from int to float and back) by this because floating point multiplication is faster than integer division.

lets say we culating 20% of a number.

In integer you do: result = 20*value/100;
But with float: result = value * 0.20f;

it’s clear that float requires one operation less, you only do multiply, not the division.

When you’re doing that on a large array of pixels, to darken a texture it make sense, to rescue the number of operations.

Last edited by NutsAboutAmiga on 27-Aug-2022 at 01:38 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hypex

I'm confident TKG does some form of RGB pixel calculation because it does realtime lighting and additive blending effects too. I just don't see how you'd do those in pure 8 bit LUT, but you could easily make a 15 bit to 8 bit lookup table of remapped RGB to palette. I doubt the colour resolution is better than that, due to the size of the tables needed to remap (though if it calculated at 24 bit, it could easily throw away the lower bits to get a more manageable truncated RGB value). Also, as I say, it's an evolution of the AB3D engine which absolutely does RGB rendering.

_________________
Doing stupid things for fun...

@NutsAboutAmiga

Quote:

I guess 12bit is faster to color reduce, maybe it has to do with cache sizes.

I don't know what depth the images are stored in. But in the case of AB3D with chunky copper 12 bit makes sense since it spends it's time storing words into the copper list to set pixels. But on AGA sprites were also used in chunky coppers. Though they shared palette so still possible to set all pixels as palette entries.

I don't know how the rendering was done. Direct or cached in ram. Nor if it translated from index bytes to palette words.Quote:

if replace the 12bit with 16bit that be better, for RTG. no conversion. yep 24/32bit cost more then its worth.

With my early tabled mode I needed to scale 11 bits to 64, since adding each byte of a 64 bit value results in a 11 bit value, but ramping it up got slightly complicated. In the end it wasn't worth it. Trying to scale 8 bytes down with addition doesn't work very well.

But going from 12 to 15 another story. Doubling like 12 to 24 is easy as it can be done by multiplying by 0x1001. 12 to 15 needs decimal or look up table.

Last edited by Hypex on 27-Aug-2022 at 02:37 PM.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Karlos lets say we culating 20% of a number. In integer you do: result = 20*value/100;

This depends on your range and precision requirements. On an 060 you could do (51*value)>>8 which would give you an effective multiplier of 0.19922 and has no division. You are only looking at a couple of cycles for this case, versus tens for the division based approach.

Quote:

But with float: result = value * 0.20f; it’s clear that float requires one operation less...

That's not always true as you have to move the value to a floating point register also, then back. However it's the time these instructions take. Maybe 3 cycles for a floating point multiplication versus around 30 for an integer division.

Last edited by Karlos on 05-Sep-2022 at 09:05 PM.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Doubling like 12 to 24 is easy as it can be done by multiplying by 0x1001

Or just channel << 4 | channel, which is the same thing. Mind you, given the theoretical best case instruction timings on 060 I'm not certain which will be faster :)

Also, for a table of just 16 8-bit entries, well that's a lookup in a cache line.

So the answer is, you try them all and measure carefully.

Last edited by Karlos on 27-Aug-2022 at 02:55 PM.

_________________
Doing stupid things for fun...

@Karlos

Yep, shifting work fine for 50%, 25%, 12.5%
Let’s say wanted to composition where take 25% of colors RGB from one image,
and 75% from other image, your kind a in trouble. Shifting is useless on 20% or 75%.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Karlos

Quote:

Doubling like 12 to 24 is easy as it can be done by multiplying by 0x1001


a 12bit RGB valur R is 10, G is 5, blue is 2, in hex 0xA52
you multiplying by 0x1001 and you get 0xA52A52, your wont get 0xAA5522

Quote:

@Hypex
Or just channel << 4 | channel, which is the same thing. Mind you, given the.


Yep shifting etch RGB channels will work, but you can't shift all channels in one operation.

Last edited by NutsAboutAmiga on 27-Aug-2022 at 03:35 PM.
Last edited by NutsAboutAmiga on 27-Aug-2022 at 03:34 PM.
Last edited by NutsAboutAmiga on 27-Aug-2022 at 03:30 PM.
Last edited by NutsAboutAmiga on 27-Aug-2022 at 03:29 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Shifting for 75% is fine, you just merge the results of shifting right once and twice, masking off any bits that would spill from one channel into the next. I use it for light motion blur effects in my php demo engine, by creating a 75/25 mix of the current and previous frame:

https://youtu.be/koEwVBM4a3U

It's PHP code but it's close enough to C to understand. Each pixel in the buffer is a 24-bit RGB value and we use shifts and masks to blend together two different values using either 25/75, 50/50 or 75/25. The whole RGB value is manipulated at once.

Regarding 20%, or pretty much any other value, you can use multiply/shift right if you hate division, but precision is affected.

Last edited by Karlos on 27-Aug-2022 at 03:43 PM.
Last edited by Karlos on 27-Aug-2022 at 03:37 PM.
Last edited by Karlos on 27-Aug-2022 at 03:32 PM.

_________________
Doing stupid things for fun...

@Karlos

I love how every thread I start ends up about coding tricks one way or another, no matter what it starts off as...

Last edited by Karlos on 27-Aug-2022 at 04:06 PM.

_________________
Doing stupid things for fun...

@Karlos

xD
You know, quake III was improved massively at the time due to a trick. Tricks are good!!!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

The reciprocal square root algorithm is good but it's not why quake 3 was as fast as it is. A lot more can be attributed to the fact that it used a rendering path in which GPU vendors only had to focus on optimising a single drawing call in their drivers, specifically the indexed triangle list operation. Quake 3 uses this drawing call for almost everything.

Last edited by Karlos on 27-Aug-2022 at 07:07 PM.

_________________
Doing stupid things for fun...

@Karlos

CUE A NEW THREAD ABOUT GLDRAWELEMENTS VS DISPLAY LISTS









/mega

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@MEGA_RJ_MICAL

No, it'll just be another excursion in an existing one. The approach worked mind, I remember tweaking the implementation of W3DHW_DrawElements() in the Permedia2 driver to improve this. Although it was still basically unplayable on the BlizzardPPC (except in the lowest detail against easy bots), on the CSPPC it was actually fast enough to be playable. One of the greatest ironies of Quake 3 was that most competitive players tended to use the low detail settings deliberately anyway as it removes all the distractions from the action.

Regarding the fast reciprocal square root trick, on PPC this has an alternative implementation that uses a specific instruction that returns the initial estimate and then the trick is to refine it with an additional Newton Raphson step.

_________________
Doing stupid things for fun...