macOS support, cross-platform improvements, and bug fixes

[zverinapavel]

This PR adds significant improvements to FPC Atomic:

New Features

• ✅ Native macOS builds (Apple Silicon and Intel)
• ✅ Cross-platform multiplayer compatibility (Windows, macOS, Linux)
• ✅ Enhanced controller support (up to 4 players locally)
• ✅ Cloud server deployment on Fly.io
• ✅ CI/CD automation for automated builds

Bug Fixes

• Fixed Windows BASS device initialization error
• Fixed cornered animation bug
• Fixed network game join on localhost
• Fixed relative destination path for CD Data extractor on macOS
• Various logging and debugging improvements

Technical Improvements

• Network optimizations
• Better error handling
• Improved build scripts
• Automated release workflows

All changes maintain full compatibility with the original game mechanics. The original author is properly credited in the README.

Tested on:

• macOS (Apple Silicon and Intel)
• Windows

Not tested on:

• Linux

[zverinapavel]

Hi Uwe,

i have just created the pull request.
Please take your time going through all my changes.
Some of the changes were hard to figure out, how to combine running on Windows and also on Mac.
The SDL and some other stuff works differently.

The Updater functions are not implemented on MacOS,
and also CI/CD works on gitHub for Windows and Linux only.

The Builds for mac are done locally, with my Apple developer account.

Thank you very much,
and I look forward to work with you.

Pavel

[PascalCorpsman]

Feedback on your Pull Request

First of all: wow. I am genuinely impressed that you took the time and effort to dig into my codebase. Most people would not even try, and your motivation and persistence really stand out. Thank you for that.

Unfortunately, I cannot merge this pull request directly.

The reasons are not about the intent or the ideas — many of them are good — but about scope and constraints:

The PR is extremely large and touches many unrelated areas at once.

Some changes break existing functionality or project assumptions.

Some included content may violate third-party copyrights.

A few changes conflict with the current architecture or toolchain.

Because of this, a direct merge is not possible. That said, I do plan to manually adopt and re-implement many of your ideas, because the core concepts are often correct and valuable.

How changes are usually handled.

For maintainability and quality reasons, changes are usually broken down into small, isolated steps (features, fixes, refactorings).
Each step can then be reviewed, discussed, and merged independently. This keeps the codebase stable and legally clean.

Your PR contains many such “small workloads”, which I would rather treat as individual feature requests. Below is a structured overview of what I found, including my initial thoughts.

Review of Individual Topics

General / Repository

• Default line endings not defined
  
  → Yes, I will fix this ASAP. The invalid line endings completely break GitHub’s diff view; I had to use external tools to review the changes. -> Did, now is CRLF, but not shure if this is a per client setting..

cd_data_extractor

• Fix ANI files that are incorrect
  
  → FixAniFileIfNeeded(const AniFilename: String): String;
  
  I need a concrete example. My existing .ani files do not show this issue.

• Default locations / Darwin-specific defines
  
  → Is this really required on all macOS systems?
  
  Lazarus already provides mechanisms for storing/loading such values. I have not used them yet, but this likely needs refactoring. -> Did

Client

• Default filename for atomic configs
  
  → Lazarus provides a helper for this; I will switch to it. -> did

• uearlylog.pas
  
  → I do not see the benefit. ulogger.pas should be sufficient.
  
  I will merge this with the “write logs to writable folder” topic. -> Now the logger should be able to log in all states

• Logger directory should be writable / global log folder
  
  → Agreed. Will be done. -> did

• Flame rendering looks wrong
  
  → You added a lot of code. I need to review it carefully, but the idea seems reasonable.

• Keep aspect ratio on window resize / smoother rendering
  
  → Good idea. Will be integrated, done

• Always show IP/Port screen on Join
  
  → Good idea. Will be optional. -> I made it automatically popup after 550ms, if there is no local game found (and close automatically if later a server opens up), hope this is a good compromise

• Game controller support
  
  → i moved all SDL code into a separate file and treated the inputs as keyboard, thus made the SDL Input usable for the complete game, also i ported the needed parts from SDL2 to fully use the Gamecontroller, with this i wrote a new usdl_gamecontroller.pas and added this to all dialogs, i hope this also fits your needs ;)

• Increase framerate to 50 FPS
  
  → Will be tested. If no negative side effects occur, it will be integrated. -> done smooth now

• Increase timeout
  
  → This seems rather high. I tested over LAN and internet in Germany without issues. Maybe this should be a server-side option.

• Inter-frame interpolation for keyboard input
  
  → I need to fully understand this before integrating, but the idea sounds promising.

• Show server IP if available
  
  → Sure. -> done

• Return key works on all screens
  
  → Sounds fine, but needs testing, seems to be only in "Join" dialog missing ;)

• Always show key labels in LoadPlayer screen
  
  → This deviates from the “original”, but I am okay with it.

• Show available joysticks in player menu
  
  → I do not fully understand this. Shouldn’t this be handled by the launcher?

• More error handling during startup
  
  → Agreed, but your approach violates DRY. I will rework this more elegantly.

• Outdated bass.pas
  
  → Yes, this needs an update. -> Done

• Enable DMIX
  
  → No issue on Linux and Windows, but macOS seems problematic. This deserves a dedicated ticket and discussion.

• Check for existing files during game start
  
  → The launcher already validates files. If used as intended, these checks are redundant.

• Updater supports release ZIPs instead of single files
  
  → I am still learning GitHub releases. I will try to align this with common standards.

• Fly.io support
  
  → Interesting idea. I need to evaluate what is required.

• macOS support
  
  → I would love this. However, I cannot test it myself. I will need Docker support and at least one macOS user willing to test.

• Improve CI/CD using GitHub mechanisms
  
  → Agreed.

• Purple artifacts in images
  
  → See “Units” section below. -> Actually i think this is a topic for the CD_data_extractor ..

• Ask on Close and on Exit actual game
  
  → done.

Launcher

• Run launcher detached
  
  → Seems to be a macOS-specific requirement. OK.

• Cyclic reload of side image
  
  → Not sure if I like this, but it can be done.

• Use fphttpclient instead of Synapse
  
  → Needs testing. Especially on Windows this is non-trivial.

Server

• More detailed startup information
  
  → Sure. but ignore docker ;) (if you use server in docker run with -d param)

• More details during AI loading
  
  → Sure.

• Store stats in a writable folder
  
  → Same as client/launcher. Can be done. -> did

• Invalid sound propagation
  
  → HandlePlaySoundEffect does look suspicious. Needs deeper inspection.

Units

• Including external libs/code
  
  → Not acceptable. These are available elsewhere and may violate copyrights.

• Hash calculation not platform-independent
  
  → True. Needs fixing.

• Invalid animation locking
  
  → I was not aware of this. Will investigate.

• Incorrect “end flame” calculation
  
  → Will check and fix. (see also client ;))

• TOpenGL_GraphikEngine.LoadAlphaColorGraphik alpha handling
  
  → Idea is fine, implementation is not. I will replace it properly. -> Isn't this a issue of the cd_data_extractor ?

• usynapsedownloader.pas
  
  → Does fphttpclient support proxies? If I switch, I will create a new downloader. A Synapse downloader without Synapse makes no sense.

General Concerns

These topics either seem questionable to me or require further clarification:

• Using FPC instead of Lazarus IDE
  
  → This caused multiple reimplementations and broke the Lazarus build (e.g. removal of LNet*). If it builds with FPC: fine. But the official IDE remains Lazarus.

• ResolveResourceBase introduces DRY violations
  
  → If truly needed, it should live in a shared, central unit.

• More build modes (especially for Darwin)
  
  → The project intentionally has only Debug and Deploy. I do not yet see why macOS needs additional modes.

• Copyrighted content (e.g. images)
  
  → This cannot be merged under any circumstances.

• Early logger and dead logging code
  
  → Will be removed. -> ulogger should now be capable of logging everything

• Threaded chunk manager
  
  → Makes little sense on Windows due to time slicing. If macOS truly needs this, it must be implemented via a derived class, not injected globally.

• Non-English documentation or AI-generated content without disclosure
  
  → Only English documentation is acceptable.

• Debug code that cannot be disabled
  
  → Will be removed or deactivated. -> as we do not merge, but reimplement, this is not an issue ;)

• Disk writes during gameplay (uatomic_field.pas)
  
  → Writing to disk during detonation/rendering is not acceptable. -> as we do not merge, but reimplement, this is not an issue ;)

• ulogger.pas file encoding broken
  
  → Aside from that, the changes look useful. I will try to merge them manually. -> did

• Moving “data” to another location
  
  → Is this macOS-specific? Likely related to ResolveResourceBase. This needs discussion and should probably be optional via the launcher.

Final Notes

To be very clear: I really appreciate your work and the effort you invested.
I am absolutely willing to integrate as many of your ideas as possible — manually, carefully, and legally — without breaking the project.

However, this must happen in small, reviewable steps, not in one massive change set.

If you are okay with this approach, I will re-implement features one by one, using your code as a reference and inspiration. Since everything happens publicly, you are very welcome to act as a reviewer, provide feedback, and suggest improvements along the way.

Once this is done, two larger topics will remain:

• macOS port
  
  → Requires a dedicated ticket, longer discussion, and your help, since I do not have macOS hardware or a release pipeline yet.

• Fly.io support
  
  → Also requires a ticket and discussion. I like the idea, but it needs proper planning.

Again: thank you for the contribution. I hope you stick around — your input is valuable, and with a more incremental approach, we can get a lot done together.

[zverinapavel]

Hi Uwe,

thank you very much for this deep analysis and all comments.
I totally agree to split this massive Pull Request into small issues, and implement them one at the time.

I agree with most of your detailed comments.
You have found some of my mistakes (i have forgot to remove them, and clean them up).

I am ready to cowork with you, just let me know how would you like to work on it.
Will you create separate issues, and i will cooperate somehow on them?
Or do you want me to comment each point of your feedback?

Looking forward to work with you
Pavel

PS: Your work is amazing, and you made my dream come true - play online Atomic Bomberman with my son :-)

[PascalCorpsman]

Hi Pavel,

as you maybe already saw, i started "porting" your patches to my codebase, i will keep the #12 (comment) post updated and strike out everything what is "done" in my opinion ;) (please test if the solved issues fit the MacOS variant as well, or if it needs more adjustments).

At 3. January 2026 i plan a little test session with some of my friends, so atm i am hurrying up as much as possible to port the "most" benefit patches into the game to be tested.

I agree with most of your detailed comments.

I am interested on your opinion, feel free to share ;)

In the mean time it would be nice if you can answer the following questions:

• can you provide / give a link to a .ani file that made the "FixAniFileIfNeeded" patch necessary ?
• I think "patching" the Purple issue makes more sense in the cd_data_extractor instead of the graphik engine, can you give examples of the .png files, so that i can test and extend the cd_data_extractor ?
• MacOS Build: i use the docker file from https://github.com/ChrisWiGit/lazarus-docker to build Linux and Windows version, maybe you find a way to modify it to also create the MacOS builds ? At least we need to exchange the images you created as they are not legal..
• Is it true, that you do not use Lazarus to build the code ? (and if so why?)

[zverinapavel]

Hallo Uwe,

Sorry for long pause, the Christmas vacations, New Years Eve, and lot of unexpected work beginning of January. I want to help and contribute to this project, as much as I can.

Here are my notes.
I tried to answer everything in your text. I would like for the future focus just on small isolated issues, and I am ready to help. :-)
Thank you for your patience.

• can you provide / give a link to a .ani file that made the "FixAniFileIfNeeded" patch necessary ?

https://drive.google.com/file/d/1PjFbBGCB-KRcNwsGN8RdXII1K_AcGsOg/view?usp=share_link
Here are 2 files. The bad one and the corrected one. I this the file is from full CDRIP. Both files has same size, but the wrong one begins with 00. Solution was to ignore the 00 byte. I tried to create solution, if more file from different sources has this same issue.

• I think "patching" the Purple issue makes more sense in the cd_data_extractor instead of the graphik engine, can you give examples of the .png files, so that i can test and extend the cd_data_extractor ?

Yes, that will be better. I don’t have code for work with ANI files.
So I had to work with created PNG files. F.E. the file bigfont.png had the keying problems.
https://drive.google.com/file/d/1gpLV1rm1lP6Z1dQa_b8jvzYAWGPqJ5ft/view?usp=share_link

Here is explanation screenshot.
https://drive.google.com/file/d/1wQ-vpLk79Ju9K1Wl3vRRt-YAD9IOR4U0/view?usp=share_link

• MacOS Build: i use the docker file from https://github.com/ChrisWiGit/lazarus-docker to build Linux and Windows version, maybe you find a way to modify it to also create the MacOS builds ? At least we need to exchange the images you created as they are not legal..

I need more time to investigate building flow for MacOS, It is more complicated, than Windows, and Linux. With each new MacOS version, there are more security rules, for running unknown software. As far as I know, the user has to heave paid Developer Account from Apple, and the aplication needs to be signed with Developer Certificate, and should have Aprrovement from Apple, that is does not contain Malware. The process is very complicated. And if it is not signed, than this Application does not run. The app cannot access the files in the Data folder. (Data created by CD_Data_Extractor.).
I make the MacOS builds on my computer right now.

• Is it true, that you do not use Lazarus to build the code ? (and if so why?)

I used Lazarus v 3.9 for macOS.
I was not using Lazarus IDE. I was using VS Code with Pascal support.
But for building I used lazbuild from Lazarus 3.9 runned from terminal command line.
I believe I did not use FPC (free pascal compiler alone, but if so, it was done by accident).

Review of Individual Topics

cd_data_extractor
Fix ANI files that are incorrect
→ FixAniFileIfNeeded(const AniFilename: String): String;

I need a concrete example. My existing .ani files do not show this issue.
I have sent the example ...

Default locations / Darwin-specific defines

→ Is this really required on all macOS systems?

Lazarus already provides mechanisms for storing/loading such values. I have not used them yet, but this likely needs refactoring. ->

MacOS has these specific rules for security. It is not common, and restricted to save something into Application Directory (where the Apps/Games are stored - Similar to Program Files in Windows). The best and safe practise is to save data into Library/Application Support/ And the data folder sometimes in runtime is not visible from another App (fps_atomic).
If something is not 100% correct, the system can block access, or the saving some files, or create random folder, not accessible next time. I had headache solving all issues.

Client
Game controller support
→ i moved all SDL code into a separate file and treated the inputs as keyboard, thus made the SDL Input usable for the complete game, but could not figure out what you did with the gamecontrollerex thing .. yet.
The idea was, that there are 4 possible controls on one computer - Keyboard 0, Keyboard 1, Joy 1, Joy 2. User can chose the controls after Join Game.
If the Joy 1, and Joy 2 are not connected / active on the computer, these will be skipped, when selecting Player controller.

Increase timeout

→ This seems rather high. I tested over LAN and internet in Germany without issues. Maybe this should be a server-side option.
Inter-frame interpolation for keyboard input

→ I need to fully understand this before integrating, but the idea sounds promising.
I live in Prague in the very center. There are dozens of Wifi networks around me. I have the standart router/modem from Vodafone, and I had very strong problems with packet thrusting, and sync issues. On 2.4 wifi network, it was nearly impossible to play the game. The user experience was extremely bad. This interpolation makes the playing experience much smoother. And works without issues. Please check it.

Always show key labels in LoadPlayer screen

→ This deviates from the “original”, but I am okay with it.
Show available joysticks in player menu

→ I do not fully understand this. Shouldn’t this be handled by the launcher?
I think this picture illustrates, why this is important. Users need to see, which controller is which. I think this was same in the original Atomic Bomberman.
https://drive.google.com/file/d/1zTyQs4SaU1of7M-RSXsOHAQlJDWt7lQx/view?usp=share_link

More error handling during startup

→ Agreed, but your approach violates DRY. I will rework this more elegantly.
Yes, please :-)
Enable DMIX

→ No issue on Linux and Windows, but macOS seems problematic. This deserves a dedicated ticket and discussion.
Agree. Ready to talk about it.

Check for existing files during game start

→ The launcher already validates files. If used as intended, these checks are redundant.
My goal was, to give a user graphical feedback, when CD_data_extractor successfully extract the files, the picture of bomber man will appear in Atomic Launcher immediately. Now it appears (on Mac) only when the Atomic Launcher is restarted. Maybe there is clean solution to this. I am leaving this on your decision. :-)
Updater supports release ZIPs instead of single files

→ I am still learning GitHub releases. I will try to align this with common standards.
Yes please. I am not 100% sure if I made it right.

Fly.io support

→ Interesting idea. I need to evaluate what is required.
It works on my forked version. And it works like a charm :-)

macOS support

→ I would love this. However, I cannot test it myself. I will need Docker support and at least one macOS user willing to test.
I will help you test it and / or do the research. As I wrote before, there are a lot of security staff around this (certificates, signing the app), and paid developer account might be needed for build and distribution. I can create a build for you, which you can have in releases. Signed with my developer account. If this will suits you.
Improve CI/CD using GitHub mechanisms

→ Agreed.

Purple artifacts in images

→ See “Units” section below. -> Actually i think this is a topic for the CD_data_extractor ..
I agree. I needed to solve the issue in game, because I do not have correct utilities for working with ANI files on MacOS. Leaving this up to you :-)

Launcher
Run launcher detached

→ Seems to be a macOS-specific requirement. OK.

Cyclic reload of side image

→ Not sure if I like this, but it can be done.
My goal was, to give a user graphical feedback, when CD_data_extractor successfully extract the files, the picture of bomber man will appear in Atomic Launcher immediately. Now it appears (on Mac) only when the Atomic Launcher is restarted. Maybe there is clean solution to this. I am leaving this on your decision. :-)

Use fphttpclient instead of Synapse

→ Needs testing. Especially on Windows this is non-trivial.
OK.

Server
More detailed startup information

→ Sure. but ignore docker ;) (if you use server in docker run with -d param)
More details during AI loading

→ Sure.
Store stats in a writable folder

→ Same as client/launcher. Can be done. -> did
Invalid sound propagation

→ HandlePlaySoundEffect does look suspicious. Needs deeper inspection.
Units
Including external libs/code

→ Not acceptable. These are available elsewhere and may violate copyrights.
I can’t remember now, which external libs/code have I used. Can you tell me, which you have in mind? But I agree, not to violate copyright.
Hash calculation not platform-independent

→ True. Needs fixing.

Invalid animation locking

→ I was not aware of this. Will investigate.
Incorrect “end flame” calculation

→ Will check and fix. (see also client ;))

TOpenGL_GraphikEngine.LoadAlphaColorGraphik alpha handling

→ Idea is fine, implementation is not. I will replace it properly. -> Isn't this an issue of the cd_data_extractor ?
Yes, please. If you can solve the issue in cd_data_extractor - it will be best solution. I couldn’t do this.
usynapsedownloader.pas

→ Does fphttpclient support proxies? If I switch, I will create a new downloader. A Synapse downloader without Synapse makes no sense.
Yes, Fphttpclient supports proxies. I had some issues with Synapse on Mac.
I left the class name there, so I don’t have to change all calls. And break something there …

General Concerns
These topics either seem questionable to me or require further clarification:
Using FPC instead of Lazarus IDE

→ This caused multiple reimplementations and broke the Lazarus build (e.g. removal of LNet*). If it builds with FPC: fine. But the official IDE remains Lazarus.
I used Lazarus v 3.9 for macOS.
I was not using Lazarus IDE. I was using VS Code with Pascal support.
But for building I used lazbuild from Lazarus 3.9 runned from terminal command line.
I believe I did not use FPC (free pascal compiler) alone, but if so, it was done by accident.

Also, I didn't remove LNet - I only changed how it's obtained: instead of a git submodule, it's now downloaded during CI/CD builds (and kept in macos/third_party/lnet_src/ for local macOS development) to simplify the build process and avoid submodule issues.

ResolveResourceBase introduces DRY violations

→ If truly needed, it should live in a shared, central unit.
OMG, I have the same function 3 times.
I was duplicating it, while testing, and forget to refactor.
Please can you clean this mess, and have only one lets say in uatomic_common?
This is really needed in MacOS, when the app is not signed, it behieves differently. When the function is in shared location, I will test it again, and maybe simplified it.

More build modes (especially for Darwin)

→ The project intentionally has only Debug and Deploy. I do not yet see why macOS needs additional modes.
I need to have switch for MacOS builds for old Intel CPU'S (x86_64), and Apple Silicons CPU’s. (Arm64). Maybe there is better solution than build modes. Can you help me with this?

Copyrighted content (e.g. images)

→ This cannot be merged under any circumstances.
Yes, Agree. My intention was to have some icon for the app, so I have created one for myself, and forget to remove it from the project, However, I would love the app has an icon - can we create one from files via cd_data_extractor?

1. From Icon from BM95.ico file?
https://drive.google.com/file/d/1BSzDTog-GHD23TzU1k8LKDd1xSJ9VrCd/view?usp=share_link

2. Or via script as a cut out from mainmenu.png?
https://drive.google.com/file/d/1TO6qimaHnWBVAyKFmBk3bJylZ3uuVNoA/view?usp=share_link
cut out 
https://drive.google.com/file/d/1J_WNnO1NPcGmmXLjCP_-isUPpzV32dFz/view?usp=share_link

Threaded chunk manager

→ Makes little sense on Windows due to time slicing. If macOS truly needs this, it must be implemented via a derived class, not injected globally.
Yes, this is needed on MacOS. Without it there were issues - the time running in the clients was slowing down, when clients were out of sync, happened via packet thrusting on Wifi networks. Can you implement this as derived class?
Non-English documentation or AI-generated content without disclosure
My mistake, I can rewrite everything in English. Or correct everything needed.
Moving “data” to another location

→ Is this macOS-specific? Likely related to ResolveResourceBase. This needs discussion and should probably be optional via the launcher.
Let’s discuss this more. I can explain to you, how this works on Mac, what is causing problems, and what is not allowed. Let create separate Issue for this.

My Final Notes
I tried to answer everything, and I am ready to work / contribute with you in the future.
If possible, please create Issue for each problem we are facing, and I will collaborate as much as I can.

I love what you have done, and I play this atomic bomber man version with my son, and with my friends.

Looking forward to work with you.

Pavel

[PascalCorpsman]

Hello Pavel,
as we both have working versions i am not in a hurry to get this things done fast, instead i want to do it right ;).

Saying this i have had a further look into the clFuchsia issue.

First, if i run the cd_data_extractor with a bunch of images that i found via google, and run it with my orig CD-Version, it alway's extracts the bigfont.png correct, so there is no issue or i did not get how you created your "invalid" bigfont.png (because the one you shared is definitly not correct).

Also if i get your writing right, you created your data folder with this "corrupted" .ani files. So i am not shure if we are heading into the right direction by supporting corrupt files and having lots of continued issues, if the solution is to use one of the other "correct" versions which are easily accessable via a google search?

Maybe you could test, if you have the same issues, if you choose a different source ?

To be able to run my code with darwin i think the following steps are needed

• include the "data" folder moved patch
• Threaded chunk manager

Did i miss something, or should the code run on darwin after this ?