@Capehill
I made pretty much the same in 2016 as a testbed for ogles2 and Nova, I however called it ShaderBoy


I totally forgot about it; back then Nova supported not enough shader commands for it to be fun.

Version 2.5 available now!
Version info
Downloads and other info
(I didn't upload it to the Amiga depots yet, use my homepage or the online updater for now)

Cheers,
Daniel

@polluks
I didn't bother with any demo versions.
However, feel free to mail me a zip of your bombdemo install (all of my Windows systems refuse to even run the setup.exe of this demo and I have no 9x or XP emu installed right now, so...).
Then I'll eventually take a look and maybe make the remake compatible with that package. However, if I do that then I'll also add any limitations of the demo.

Version 2.4 available now!
Version info
Downloads and other info

Cheers,
Daniel

@328gts
Cheers, mate! Year round driver here

Quote:
That remains to be a really weird mystery. I think I will simply counter this with an artifically reduced scissor rect (by one pixel at each border). This would simply cut the pixels that would otherwise later remain as garbage I will make that an optional feature, to be explicitely enabled by tool type.

@K-L
@Lio

Cheers

@Lio
Quote:
I didn't even know that there was a localized french version. I know that the original game's texts are inside its MESSAGES.TXT file and that it can be easily localized, but I didn't know that it was actually done. I bought my own CD in Germany back then and it's english nevertheless (and IIRC that's true for all my university friends' copies too), AFAIK there was no German localization.

But I didn't care about that MESSAGES.TXT file anyway, mostly because my rewrite has different / improved menus. E.g. the original has no profiles mechanics / menu at all. And I also didn't care about localization in this case, that's why it'll always be English no matter what (too lazy ).

Quote:
Aaah, solo is no fun. I didn't put any effort into the AI, just enough to have "something", mostly for when I'm test-playing alone. It's pretty much equally useless as in the original, maybe even dumber (but well, its "ThinkAndMakeDecision" function is less than 100 lines incl. comments, so... ). Depending on the map it can be okayish but most of the time it's plain dumb.

@all
It can also be run on Android Thanks to Valentin for trying and recording.

And here's the dedicated Youtube playlist which contains all the dev recordings so far.

@jabirulo
Quote:
That's what the "compositing" version is for

@Joeled
Cheers

@Breed
Quote:
Great, that's what it's meant for Have fun!

@all
New version 2.3 available (or available soon, depending on where you get it)...
Only minutes after the 2.2 release I was informed about a dumb bug:

- Fix: conveyor belts didn't transport players anymore :P This bug was introduced with v2.0 when the core logic was modified to use fix-point math instead of floats for networking and slipped through unfortunately (I had commented out some parts and forgot to reactivate them). Thanks to Valentin for reporting!

And while I was at it:

- when fixing the above bug the player movement logic was improved too. Funny enough all this also made the rewrite a bit more exact by "accident": in the original the conveyor belt has no impact if you try to move in an orthogonal direction, this is now correctly replicated.

- new gfx option "stretch" to disable the aspect correction. For those who prefer blown-up bombermen and no black borders like Valentin.

- network sanity check: only identical program versions can connect for an online match. If you try to join a session with a different version, you'll be kicked immediately.

Atomic Bomberman Fan Rewrite 2.2 Corona Edition

Because Corona and social distancing suck hard, I decided to somewhat help to make the latter easier to handle. That's why this new version got an online gaming feature! And actually a pretty nifty one:
not only can you run a mixed shared game-session with AmigaOS4-, MorphOS-, AROS- and Windows- (and maybe Linux, Wine should do) machines, no, you can also do e.g. a 6 player match with 4 players on machine A and 2 players on machine B.

Note that, just as with the previous versions, this here is a "player" application which requires the original game CD data from back then, check the readme for further details and instructions.

Also note: the network code is a quick shot, done only in a couple of days with only minimal testing. Internally the whole core game logic has been modified to become float-free so that the logic is now 100% deterministic no matter which machine / system. This in turn allowed me to only transfer player inputs and frame timings around, each client then runs the game as usual.

Anyway, I uploaded it to os4depot and AROS Archives (it's still in the upload queue, watch for version 2.2 to come available!) and Papiosaur already put in on MorphOS storage (thanks mate).
You can also get it from my homepage, there you'll also find the Windows version.

And now: tchatching!

@Hans
Quote:
Absolutely. Whoever came up with the idea to do such auto-conversions instead of telling people to use text-editors which correctly handle and preserve line endings is a strong candidate for a good amount of tars and feathers.

Quote:
In TortoiseGit's dialog you can set it based on repo or globally. After all it's just an entry in the .git/config file ([core] section, autocrlf=false), unless there's a .gitattributes file with overruling definitions

@Hans
Quote:
Naa, there is a setting for this (Settings -> Git -> Auto Crlf convert). IIRC it's set to don't mess around with the line endings anyway (I don't know about outdated TortoiseGit versions though), so there's no problem. I just checked with a hex-viewer, to make sure: line endings from the Odyssey repo are well preserved.

@kas1e
Thanks a lot for all the effort!
Funny enough I just saw that there was a huge, well, "discussion" on amiga.org where some people came up with the old "make AOS open-source, that would solve all problems" idea This here would be a nice test case for those claims. I'm not too optimistic though...

@Hans
Right, totally forgot about this :P

@all
Then I can definitely recommend this one here, I love fanless stuff Performance is fine, and the 1GB are good enough for me and most likely every game available on our system anyway.
Only tested in my X5000, not in the sam460ex!

@arfcarl
This is the one, it effectively covers the PCI slot too, due to the fan construction. In my case this is no problem because that PCI slot isn't used anyway.
However, I also have this one which works flawlessly in the sam460ex too, single slot.

@PEB
I can't say if this one works, didn't test it. If you look here a similar card is mentioned as working, so I asume chances are good for your finding, but no guarantee from my side
If I were you I'd give it a shot Although I have no idea how well that 240 performs on AOS4 right now.

@all
I also have this one here, a passively cooled R7 250 1GB. Had this in stock and just put it into my X5000, works well but looks as if not all VRAM is being accessed, system reports only 200+ free VRAM MB after cold boot (on a pretty clean system), which is still good enough for me but I probably wouldn't recommend this one because of that.

@BobSacamano
Quote:
Then don't get a Polaris for now, because there is no classic Warp3D support for those cards at all and only unstable hacky MiniGL support via MiniGL4GL4ES at the moment!
I'd recommend the Sapphire R7 250 2GB DDR5: full 3D support, performance more than good enough for everything on AOS4 (and there will certainly be another extra boost once we got DMA/GART), pretty silent.
I have that one installed in three systems here (X5000, Tabor and sam460ex), very satisfied with those!
Only problem: may be hard to find by now

@lazi
Thanks

@jabirulo
Thanks & great

@thread
The MorphOS demo has just been updated. Unfortunately the latest MorphOS 3.13 contains a bug which causes the ogg decoding library to malfunction, resulting in massively distorted audio. The reason is that the floating-point rounding mode is not standard now, apparently due to some modification in ixemul. So essentially it looks as if every program which uses ixemul suffers from a rounding-mode change now. If that's a problem for the respective program depends, of course.

In my case this badly affects (at least) the audio of almost all of my games / ports like Voxelnoid, BattleSquadron, Ace Of Hearts, etc. (AFAICS only Atomic Bomberman and Tower57 aren't affected, the first because it doesn't use ogg, the other because it doesnt use ixemul). But of course you can bet your butt that it - maybe subtly - breaks all sorts of other stuff, only that in the case of the ogg decoder you actually hear the problem pretty well
I dunno if and when the MorphOS-guys publish a hotfix for this issue, which is why I'm going to provide updates for all those games in short time.

Thanks to koszer, Ernst Eiswürfel, Develin and Piru for reporting, testing and helping Those guys show real interest for the MorphOS version, not like some here who claim to do so but obviously never tried those demos on current MorphOS (or just don't care after all)...

EDIT: the MOS guys released an ixemul hotfix, so I won't waste time with updating those old games.

@kas1e
Forget all the stuff from above (edit: well, not all, I overlooked Salass' newlib inttypes.h issue). There simply is a little typo in your code:

const T y = x;
char buf_2[20] = {0};
snprintf(buf_2, sizeof(buf_2), fmt, x);

You see, you never use y...
That's how it should be:

const T y = x;
char buf_2[20] = {0};
snprintf(buf_2, sizeof(buf_2), fmt, y);

Salass' cast (T)x would do too, of course, but the true problem here is the x/y typo. And in C++ you'd actually prefer to write static_cast<T>(x) instead of (T)x, but well.

@Templario
For not having read my explanations at all you have a bit too many half-baked semi-quotations in your previous comment, but well, I guess I don't have to understand everything or everybody

@all
The MorphOS demo has been updated. Thanks to Ernst Eiswürfel, who notified me that I had forgotten to remove an old, now contra-productive "some-GPUs-have-wrong-fog-color-bug"-patch which eventually resulted in pink dogfight fog. The respective bug has been fixed in MorphOS long ago but in the demo-build the patch was still active

@mufa
Great

@Templario
I suppose you didn't understand what I wrote here and here. No offense, but maybe an english speaking spanish friend of yours can translate it to you? I really don't know how to explain the situation more clear and detailed. Also note that I never worked on any other Cinemaware projects.

@khayoz
@328gts
@samo79
Thanks, be my guest
As you can see it's really almost done. Some bugs to be fixed and a handful of gameplay details missing.

@all
Somebody uploaded the demo to MorphOS Storage. I know that this was with good intentions.
However, please don't upload those in-dev demos anywhere else.
I want to be able to quickly ( = in a minute) replace all of those ( = centralized on my server) as soon as I fix / add sth. Such external additional uploads will only result in potentially soon outdated versions floating around, causing more trouble than anything. Yes, the game has an online-update mechanism but for this to work I have to prepare update packages, version everything correctly and tell the update-server - all extra work I'd like to skip / not care about with those demos

@mufa
You are lucky
Last night I wrote a quick'n dirty MiniGL render path for Wings. At least here it works with the latest MiniGL4GL4ES, so with a bit of luck this should do on your Polaris
Grab it here.

Note: as being said - quick'n dirty, especially in combination with MGL4GL4ES which by itself is a dirty hack... So don't expect it to work 100% flawlessly and don't expect it to be too stable, especially if not running after clean boot or running for a 2nd time.

Also note that non-Polaris users should better stick to the classic Warp3D version. With the current drivers the manually optimized classic W3D render path is usually significantly faster.

Cheers,
Daniel

@mufa
Unfortunately that's "normal". The game requires true Warp3D classic, therefore no Polaris support. It does not use MiniGL.
However, adding a MiniGL render path shouldn't be too hard, after all that's pretty much identical to the OpenGL render path which is already inside for other platforms. So, if the classic W3D driver situation on Polaris doesn't improve, I will likely come up with that which in combination with MiniGL4GL4ES would support your Polaris. But right now: bad luck with that setup

@walkero
Thanks mate

@all
Some videos:

- X5000, AmigaOS4
- Tabor, AmigaOS4
- PowerMac 3,5 (G4, 512 MB, 733MHz), MorphOS
- Dedicated low end PC, AROS x86
- My cross development system, Windows10

And for comparison:
- Gameplay-Music-Video of the original PC game; accelerated and modded, but cool thanks to Celldweller
- Some matches with the original PC game (you can spot the hickups and distortions it also suffers from)