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, but could not figure out what you did with the gamecontrollerex thing .. yet.

• 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?)