@cdimauro

Maybe they just had their crystal balls set too far into the future

_________________
Doing stupid things for fun...

@Karlos

In my limited research I can't find much info on HDR apart from it becoming available a few years ago and it needs a supported video card as well as monitor.

As well as this I don't see 32 bits per channel but only 10 bits per channel. Whilst this can fit in a standard pixel size of 32 bits and increase resolution it does cut the alpha down to only 2 bits but the framebuffer wouldn't need it for the final display,

I can find less info on the actual HDR pixel format used. I found a 32 bit float format but it is a compressed HDR pixel format and what I found was for storage but not how the pixels are stored in the actual framebuffer. I also read of a 16 bit half float format but again nothing clear as to it being what the video card is using.

So it looks like HDR is rather like Amiga HAM. Higher colour resolution with hardware compression. Except 10 bits RGB a pixel can fit in lossless. Given it only looks like 10 bits are common in supported HDR hardware it still makes the 32-bit resolution of Commodore look silly to me. Now, I see 32 bits was a software construct or standard they chose, scaled down to the hardware. So 32-bit per RGB didn't mean any hardware could display 32 bits per gun, even though the functions did imply this, since they set a hardware palette. I can find no hardware that can do this and if it can then it must be very specialist and out of the league of even the most serious gamer. By the end the Amiga (A4000) was an expensive machine that didn't offer any specialist workstation graphics. This looks like putting the cart before the horse. Even the planned AAA and Hombre chipsets didn't break the 8 bit RGB limit. I still think AmigaE has the best idea with SetColour(). Takes an 8 bit RGB value and scales it down for OCS/ECS or scales it up for the OS to scale it down again for AGA. The new way was confusing for programmers, a few would have shifted it up instead of scaling. And it wasted CPU time doing conversions. Apart from being CLUT based which is more limited than even standard 8 bit RGB triplets and to an extent 16 bit RGB.

This Lenovo laptop I am using goes in the opposite direction. I read that the LCD panel is more like VGA. And it only has 6 bits per gun. Not meant to be the best. But I found there are some top laptops with HDR and 4K. Expensive ones gamers and programmers like.

Last edited by Hypex on 23-Sep-2022 at 04:14 PM.

@Hypex

More specifically the notion of 32-bit per gun (floating point usually) turns up in graphics pipelines, shader code and textures/bitmaps. Using these formats in image processing tools that support HDR is not uncommon and nor is it even a particularly new idea. There was even a version of Photogenics that used 32-bit floating point per channel.

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

_________________
Doing stupid things for fun...

@Karlos

I can understand that. The Amiga has a history of dealing with graphic framebuffers that store greater colour resolution than the display. For example 24 bit 3d renderers that downscaled a true colour render to HAM. But I like to compare like for like. Here there were functions that set up hardware palettes but the actual palette resolution was way under the input values.

@Hypex

I agree, as a colour lookup table it seems a trifle excessive.

_________________
Doing stupid things for fun...

Fixed one of the silly bugs in the game that always annoyed me, specifically that harmful floors can hurt you when you aren't actually in contact with them. Now, you can fly safely over such floors with the jetpack or pogo jump your way along to minimise contact. However, any floor damage now extends into any liquid above it, which will harm you as soon as you are partially submerged.

https://youtu.be/rkP-arxV3SY

_________________
Doing stupid things for fun...

@Karlos

Interesting.

Can I ask, what is your project about ?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

To put it as simply as possible, to turn the game it was into the game it could've been. Technically, the game engine was superior to pretty much every other doom clone and in many respects Doom itself. However the game itself was, in my opinion, released unfinished, with the following issues:

Very slow
Various bugs
Poor level design (some were good but overall inferior compared to AB3D)
Monotonous overuse of a small set of textures.

_________________
Doing stupid things for fun...

@Karlos

A reconstruction of the game then, if I understand well, nice !

What are the new specs ?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

There are two things, really. The first is to improve the engine. This is down to the hard work by pipper to make the original game source code compile. Thanks to his efforts, that's done and a few people (myself included) are making contributions to help improve it. The engine is now playable (according to some users at eab) on 030/50MHz, I've not verified as none of my physical Amigas are currently in a working state.

The second thing is a mod that I originally started back in 1996/7 that aimed to address the the basic issues with the game itself. You can think of it as a remastering project. There are new textues, objects, models, level alterations, etc.

_________________
Doing stupid things for fun...

To see the difference

Original Level B: https://youtu.be/k96Fo9ansnM

Remastered Level B: https://youtu.be/JH6HYQ49604

Bear in mind I was deliberately playing the second one at a reduced frame rate as many of the animations were coupled to the frame rate in that iteration.

_________________
Doing stupid things for fun...

@Karlos

Thanks for the background info.

Is this AGA ? 68020 Assembly ?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

Yes, it's AGA, 68020 assembler. The game sources were published back in 1997 or so, but they were pretty impenetrable, as they were basically just a bunch of lha'd directory dumps without any obvious structure. The original AB3D code and assets from both games were in there too. A treasure trove for modding with but I gave up on trying to get the engine building back then and just decided to live with it.

The repo for the current engine build is here: https://github.com/mheyer32/alienbreed3d2

Last edited by Karlos on 27-Nov-2022 at 09:07 AM.
Last edited by Karlos on 27-Nov-2022 at 09:07 AM.

_________________
Doing stupid things for fun...

@Karlos

Nice thanks, I will have a look.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

Remember not to gouge your eyes out afterwards. The AB3D2 sources were somewhat legendary. I'm not criticising, they are largely the work of one person alone, under time pressure. However there's a reason it's taken 25 years or so to get them working again. There's an ongoing effort to just improve them from a legibility perspective, even without any functional changes.

_________________
Doing stupid things for fun...

@Karlos

Yes the readability of the code is really important otherwise it is like reverse engineering from the source

But nice initiative what you are doing guys, I will definitely keep an eye on it.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

Will be amazing to see what people do with it once everything is sorted to where it needs to be.

AB3D was one of my favourite Amiga games and as much as I enjoyed the second one, glitches bugs, and general performance really sucked some of the fun out of it.

_________________
Live Long and keep Amigaing!

A1200, Power Tower, TF1260 128MB RAM, 68060 Rev 6, OS3.9 BB2, HD-Floppy, Mediator TX+ PCI, Voodoo 3 3000, Soundblaster 4.1, TV Card, Spider USB, 100MBit Ethernet, 16GB CF HD, 52xCDRom.

@Massi

Reverse engineering the source is pretty much what is going on right now ;)

_________________
Doing stupid things for fun...

@Karlos

Oh right, that is what you are doing.
Well reverse engineering the source is still much better than the binaries

Is there a specific Amiga config that you are targeting ?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

So if you look at the PRs I've raised, most of them are changes of identifier names, primarily to apply a consistent naming convention that explains at a glance what the identifier is and what it notionally belongs to. However, it's more than just renaming for the sake of it, by using refactoring tools to do this, you find all the usages and discover things like the word value in the declaration is only ever accessed as a byte, or a value is only ever written to once or even not used at all, allowing you to declutter as you go.

_________________
Doing stupid things for fun...