COBOL is not the first language anyone would ever think of when writing a First Person Shooter– after all , it’s the Common Business Oriented Language, not the Common Game Oriented Language. For Youtube-based hacker [icitry] though, that’s the point. The only way to determine if COBOL would be enough to write an FPS game was to do it.
Sure, you could rest on your laurels knowing that the language is Turing complete and therefore capable by definition, but what’s the fun in that? Now the pipeline for this game is as hacky as anything– COBOL doesn’t exactly have a robust graphics stack or a lot of libraries for pushing pixles, so he’s outputting each frame of the game as raw bitmap to STDOUT, and letting ffplay assemble the images. Control enters the same way, with the terminal set to raw input and the COBOL program reading STDIN.
As for what the images consist of, he’s going for a standard Wolfenstien-inspired raycasting shooter. [icitr] provides a decent explanation of the raycasting algorithm, along with why implementing in COBOL is a silly thing to try. That’s a theme here; he’s able to implement sprites and the logic to move and attack enemies, while constantly complaining about COBOL. If that wasn’t enough, he adds variable-height sectors to bring this much closer to a true DOOM clone. By the end, there’s a full game. It’s all up on GitHub on an Apache license.
While this video is not the most gentle introduction to COBOL, it does show you can hack the business-specific language to do whatever you’d like.
Back in the 1990s, instead of re-displaying 20 rows during scrolling in election windows, we provided a much smoother user experience by reading the screen memory, scrolling a specific area, and displaying only the scrolled record at the bottom or top. Those were the old days with COBOL.
MSwindows has been working like that for a long time. It was sometimes noticeable when because of an error, there was “random” data in the window and you scroll down and it simply scrolled the random data up, like it belonged there. Scroll it back in screen and presto, the correct data was back. It gave me a nice insight in the inner workings of this video card scrolling. With a slow-enough videocard you could even see the difference in update direction between scrolling up and down!
Pardon me, I was doing that in the ’70s…..
GCC COBOL (gcobol) or GnuCOBOL (cobc) let you call C language programs so the C packages are a resource. They are built using GCC so they use the same protocolsl as the rest of the gcc based code base. And most of those tools were written long ago and have been improved and debugged.
Both have IBM dialect support. I suspect GnuCOBOL has been compiled for use in the UNIX/Linux mainframe capabilities. GCC COBOL will be compiled for z/Series soon as well. We had to wait until the GCC 16 Release to clear the way for that work (and other good stuff.
Interesting! Do you have access to a z/Series mainframe to compile a program for it or do you use cross compilation (is so how and with which tools?)?