https://fabiensanglard.net/gebb/ https://fabiensanglard.net/about/index.html

The CP-System is also interesting, even for someone like me who never used one. But not quite as interesting (to me) as the other two.

Now imagine touching todays stuff.. Madness :)

Most commercial embedded/windows stuff I have seen usually vendored their dependencies in a thirdparty/ folder AND fixed the toolchains they use. So the setup is always reproducible.

(I'm from the "Hey as long as it works" school of thought).

Doable, but often tricky.

Cool. Cool game. I didn't know the source code was available.

My memory is not 100% correct apparently :) There is an archived repo on Github named Onlink too.

I originally read about this in a past HN thread[1], and played with the game a bit

[1] https://news.ycombinator.com/item?id=38048888

This was all pretty tedious and everything, but it was a lot of fun to high schoolers. And if we knew more computer science and software engineering we would have done more probably, and it would have worked better. But unlike today we didn't have to learn SFML or or activex or opengl to just start playing and get stuff working, we could just call circle.

The difference seems to be that there's been a greater divergence between "professional" tools and "kids/intro tools" whereas Turbo C++ (or Turbo Pascal in my days) were kinda both.

I have a ~20 line html harness which sets up a page with a full screen canvas element and gives you global window width & height variables. That’s all you need to get started. And it’s real JavaScript - so students learn a useful programming language as a result, and the advanced students can go nuts and add sprites, sound and networking if they really want to.

http://josephg.com/canvas_f.zip

I tell people to leave the html file alone and edit the javascript, using the canvas API to make it draw whatever they want. Canvas supports text, shapes and images and translations / transformations. If they want, I show them how to animate their work as well.

People make fun cursed things like this:

https://home.seph.codes/public/niamh/

A kid in the early to mid-80's could get enough working that they could imagine it possible to match a store bought game.

Once hardware capabilities went up, so did the need for more specialized skills and longer development cycles. Even though it might have still been possible to draw a box on the screen with a single command, the relationship of that box to a valuable outcome was a lot less obvious.

https://news.ycombinator.com/item?id=39323511

Or Python for 3D stuffs.

[0] https://processing.org/

If we really think basic / turbo pascal has this right. Why don’t we just teach our kids those things. We can get the environments running I am sure.

Free Logos are available even today.

https://pico-8.fandom.com/wiki/Circ

But I'm just not sure if pixel-by-pixel drawing is the right abstraction layer at this point in time.

If you search around there are some pretty decent "download InteliJ and go" things.

And everybody kept in mind that if we ever started making money from our hobby, one of our first investments would be into buying properly licensed copies of the tools we used.

Back in the day I heard about of a friend who claimed to write some 2d framework which was faster than Direct2D -- that was a pretty early version of Direct2D I think.

SDL3 is going to have a general purpose 3D API with its own shader language AFAIK.

In my experience, if what you want is to just get a window open and render some sprites, have some basic low level stuff handled and not have your hand held, SDL2 is ridiculously easy for it. There's also Raylib[0] and SFML[1], neither of which I've used but I hear good things about.

[0]https://www.raylib.com/

[1]https://www.sfml-dev.org/

That still reigns as my favorite IDE of all time by a country mile.

Thankfully a professor pointed us to XEmacs, which I managed to get my Borland experience back, which became my UNIX companion until KDevelop, Eclipse, Netbeans came to rescue.

This might be my biggest disappointment with "modern" programming. I want direct access to the hardware with stuff like $100 1GHz 100+ core CPUs with local memories and true multithreaded languages that use immutability and copy-on-write to implement higher-order methods and scatter-gather arrays. Instead we got proprietary DSP/SIMD GPUs with esoteric types like tensors that require the use of display lists and shaders to achieve high performance.

It comes down to the easy vs simple debate.

Most paradigms today go the "easy" route, providing syntactic sugar and similar shortcuts to work within artificial constraints created by market inefficiencies like monopoly. So we're told that the latency between CPU and GPU is too long for old-fashioned C-style programming. Then we have to manage pixel buffers ourselves. We're limited in the number of layers we can draw or the number of memory locations we can read/right simultaneously (like how old arcade boxes only had so many sprites). The graphics driver we're using may not provide such basic types as GL_LINES. Etc etc etc. This path inevitably leads to cookie cutter programming and copypasta, causing software to have a canned feel like the old CGI-BIN and Flash Player days.

Whereas the "simple" route would solve actual problems within the runtime so that we can work at a level of abstraction of our choosing. For example, intrinsics and manual management of memory layout under SSE/Altivec would be substituted for generalized (size-independent) vector operations on any type with the offsets of variables within classes/structs decided internally. GPUs, FPUs and even hyperthreading would go away in favor of microcode-defined types and operations on arbitrary bitfields, more akin to something like VHDL/Verilog running on reprogrammable hardware.

The idea being that computers should do whatever it takes to execute users' instructions, rather than forcing users to adapt their mental models to the hardware/software. Cross-platform compilation, emulation, forced hardware upgrades that ignore Turing completeness, vendor/platform lock-in and planned obsolescence are all symptoms of today's "easy" status quo. Whereas we could have the "simple" MIMD transputer I've discussed endlessly in previous comments that just reconfigures itself to run anything we want at the maximum possible speed. More like how a Star Trek computer might run.

In practice that would mean that a naive for-loop on individual bytes written in C would run the same speed as a highly accelerated shader, because the compiler would optimize the intermediate code (i-code) into its dependent operations and distribute computation across a potentially unlimited number of cores, integrating the results to exactly match a single-threaded runtime.

The hoops we have to jump through between conception and implementation represents how far we've diverged from what computing could be. Modern web development, enterprise software, a la carte microservice hoards like AWS that eventually require nearly every service just to work, etc etc etc, often create workloads which are 90% friction and 10% results.

Just give me the good old days where the runtime gave us everything, no include paths or even compiler flags to worry about, and the compiler stripped out everything we did't use. Think C for the Macintosh mostly worked that way, and even Metrowerks CodeWarrior tried to have sane defaults. Before that, the first fast language I used, called Visual Interactive Programming (VIP), gave the programmer everything and the kitchen sink. And HyperCard practically made it its mission in life to free the user of as much programming jargon as possible.

I feel like I got more done between the ages of 12 and 18 than all the years since. And it's not a fleeting feeling.. it's every single day. And forgetting how good things were in order to focus on the task at hand now takes up so much of my psyche that I'm probably less than 10% as productive as I once was.

The games they were producing were incredibly exciting to play at the time, but it’s even more inspiring looking back at the history to see what a handful of scrappy kids could create.

I was jealous of my friend's Mac w/ a 720 KB disk drive and 30 MB hard drive (although his system cost probably cost 6x what my PC cost).

Wikipedia has a nice article with pictures: https://en.wikipedia.org/wiki/Floppy_disk

Even if you didn't have that 3.5" drive for your computer, perhaps you can take solace in the fact that you understand intuitively why the disks were called "floppy"!

How times have (not) changed, eh?

Let's compile like it's 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - Feb 2017 (80 comments)

Real problem with implementing such a terminal-mode GUI is that Unix/Linux terminals clung to a terminal standard which didn't provide all the features of an MS-DOS text mode program. In particular, it can't recognize the Alt key by itself, or Alt+Letter key combinations. Or Ctrl+Shift+Left/Right keys.

I used it for a few of the Advent of Code days this year, but man the nostalgia wore off. Both the limitations of the IDE and the verbosity of Pascal weren't "fun" to operate in daily coming from the modern world. But definitely sweet memories.

In rainy days, I still browse through them.

For those that never saw them, they are available at the Internet Archive.

While Borland had an approach that we could get nice high level frameworks in C++ (a sentiment that Qt also shares), Microsoft C++ folks seemed keen in keeping their beloved MFC as low level as possible.

I read somewhere that MFC originally was similar in concept, but faced too much resistance internally, thus the outcome and was rewriten.

And to this day Microsoft hasn't been able to deliver a C++ framework that is as nice to use as those from Borland.

This is what AFX was. They reused some of the core pieces, so the AFX name persisted into MFC.

> but faced too much resistance internally, thus the outcome and was rewriten.

The concern was that developers who had just ascended the Win16 API learning curve would now have to ascend another totally different learning curve to understand the framework. MFC developed from a (supposedly) nice object oriented framework into a way to avoid explicitly passing handles to API calls. (It also replaced message cracking and a few other things.)

By the time Visual C++ rolled around, Microsoft started adding higher level abstractions to MFC and building it back out a bit, but the underlying damage was done.

> And to this day Microsoft hasn't been able to deliver a C++ framework that is as nice to use as those from Borland.

ATL was supposedly quite nice, as was the mostly unsupported WTL derivative (that supported complete app development).

ATL was and is, anything but nice, unless one is into deep love with COM without tooling, to this day Visual Studio still doesn't offer anything to alleviate the pain of dealing with COM, IDL and generating C++ stubs, because just like MFC and Afx, it seems there are many internal feuds against having nice tools.

The only time Microsoft finally created something nice to use COM from C++ (C++/CX), those internal feuds managed to kill it, replace it with a developer experience just as bad as ATL (C++/WinRT), and then when bored left the project to play with Rust/WinRT.

Archive: wolfsrc.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of wolfsrc.zip or wolfsrc.zip.zip, and cannot find wolfsrc.zip.ZIP, period.

curl -O http://fabiensanglard.net/Compile_Like_Its_1992/tools/wolfsr... gave a HTML file.

$ file wolfsrc.zip

wolfsrc.zip: HTML document text, ASCII text

wget downloaded the file correctly, though. can be unzipped without problem.

Yup. The link gives a 301 redirect to the HTTPS site. With wget it follows redirects automatically.

One thing that we need to rescue/reinvent from that are the TUIs which will look amazing in higher resolution screens.

Sorry I didn't get the last part of what you said, come again?