Original Age of Empires 2 dev talks about its usage of assembly code
old.reddit.com
old.reddit.com
So yes, it was the norm back then. My second job (1998), was working on a team that was going to do some software for Intel for the upcoming back then Katmai processor (Pentium I was it). It had all the new fancy SIMD instructions. The software was supposed to be something like media composer - you slap images, rotate them, etc all in realtime using software rendering (GPUs were still relatively expensive).
I wrote a bilinear and bicubic texture mapper with marching squares for transparent areas. It was all in assembly, and I spent lots of time optimizing it. Back then we used Intel's VTune, and it was super-precise (for the processors back then) - how they are going to pipeline, how much (supposedly) instructions cycles would take, waits, etc. That helped a lot!
But the real lesson was, that me and my manager - both claiming to be super good at assembly (after our recent achievements), rewrote the sphere mapping code for a game another team was writting in assembly, but alas our assembly (but no katmai instructions) code was slower than what the compiler did ;) - TBH, if we did proper mipmapping and texture swizzling we would've fared both ways, but hey, demo coders were not always to be found so they had to rely on regular programmers like us!
flipcode keeps a lot of good articles, with lots of good assembly for that - https://www.flipcode.com/archives/articles.shtml - there were even better materials from earlier years, but can't find them.
Turbo/Borland Pascal were so awesome, because they allowed for very easy of inline assembly use (somehow) than C/C++ - though you had to know which registers you can touch or not.
https://www.flipcode.com/archives/The_Art_of_Demomaking-Issu... - look for zip file with the source code.
I've also found Go version (and there were 2 java ones)
https://github.com/search?q=BlockTextureScreen
So it's not as neat as swizzling (quickly looking at it) - but essentially same goal - keep pixels that have to be drawn together at close (e.g. blocks). Mipmapping helps too, as then you don't "skip" too many pixels - and you both gain better quality and less cache misses.
This was back in the Pentium 4 era, where there were deep pipelines and oddities like some simple ALU instructions (ADD, SUB, etc.) taking 0.5 cycles(!), while others (ADC, SHR) took 4 cycles IIRC.
is there a tool that could profile/predict ahead of time, so that one does not attempt to hand write assembly before knowing for sure it will beat the compiled version?
It looks like it only supports Linux and macOS - no Windows, but no other things too like mobile.
It seems it exists for ten years, I wonder what optimizations aren't still picked by the recent compilers.
I may be getting x86 CPU generations mixed up. But having wrestled with all this, I can certainly see the appeal of hand-optimising for older, simpler CPUs like the 6510 used in the C64, where things were a lot more deterministic.
A purely pen-and-paper tool was IACA; you simply inserted some macros around a bit of code in the binary and IACA simulated how these would/could be scheduled on a given core: https://stackoverflow.com/questions/26021337/what-is-iaca-an...
Most of the time, some good optimized library would do pretty good.
One should be able to do a best-case calculation, mostly assuming caches hit and branch prediction gets the answer right. Register renaming manages to stay out of the way.
Getting more dubious, there is a statistical representation of program performance on unknown (or partially known) data. One might be able to estimate that usefully, though I haven't seen it done.
Shifts were bad however, I think they left out the barrel shifter for some ungodly reason.
Edit: Looking it up you might have worked on a larger amount of games than I thought. Very awesome nonetheless. https://www.mobygames.com/game/company:99/from:1998/platform...
AFAIK the user interface for the win9x version was drawn using native GDI windows library, and yet the PS2 version, using a completely different rendering framework and architecture, sported the very same appearance, font glitches and all. I wonder if they actually wrote an emulation layer around that.
In any event, that game, and that port, were a part of my childhood that I will always remember.
I missed that other game forums of similar vintage are now gone.
The way to being able to do Assembly in Borland products, and to lesser extent on VC++, was great.
I always feel like vomiting when looking at the mess UNIX compilers have come up for it, instead of inferring how registers are being used, and the whole string concatenation stuff.
Imagine reading this as a layman
It was written in the same C / inline assembly style. Unfortunately seemed to me like the final ASM didn't quite do the same thing as the original C.
https://liquipedia.net/ageofempires/Nili%27s_Apartment_Cup/5
How many freeform interactions like this did we lose because of the Internet's illusion of being connected?
Yeah, bouncers exist, but it should have been baked into the spec at some point.
Discord has a million deserted "servers" with redundant general channels. Peak IRC had a dozen or so large networks that often bundled a lot of e.g. adjacent FOSS projects. The chances of running into someone interesting a la the article anecdote was just higher.
Discord is a massive net negative for chatting on the internet because of this flaw imho.
The thing is, my experience is different, but of course similarly anecdotal. I essentially got my entire professional network and career on IRC, and that includes contacts all over the modern tech stack and adjacent interests, being on just two IRC "servers". And I could connect many other people in the same way.
On Discord, there seem to be just more barriers against this. Getting someone into a new place doesn't just require hopping into a new channel with a single /join command, but an entire new "server" with a new crowd. There's more inhibition against that.
Of course, the (massive) counterpoint is that you get to talk to way fewer people, particularly if they're more than half an hour traveling away. Quantity versus quality, but by having a lot of quantity through more diverse online interactions, you can find the conversations that have a lot of quality for you (overlapping fields of work, hobbies, or just a personality match).
Which is better? Probably something in the middle, where you hang out in chat rooms but are also conscious of the advantages of arranging to meet up. I do find it inspirational (too strong a word, but you get the idea) to hear of other times or cultures where things are done differently
C'mon dude. The opportunity for people to talk to one another about this stuff is unimaginably better than it was back then. Like, here we are, right now, me telling you you're full of shit. What are the chances of us being able to do that in 1999?
(I'm sorry to be mean, but I remember 1999 very well and it was much harder to get good information about things, and discuss things with others interested in the same topics, than it is today. And it was already markedly better then than it was even 5 years prior to that!)
People may say that Discord and similar will compensate, greatly, as the number of interactions can grow a lot. On the other hand, I don't think the experience is comparable to fully focusing on the person you're eating in person with.
Are Discord discussions indexed by any public search engines? What about communities that are invite-only (without much actual reason to be so)? What about community admins who decide to take their whole thing down, communities that break site-wide rules and get removed by site admins, etc? Does Discord Inc. make any commitments towards publishing discussions that have archival/historical value?
How much knowledge is already irrecoverably stuck in Slack's bit bucket, as people flocked away to the next walled-garden chat app?
With the rise of AIs-hoovering-up-everything-reachable-on-the-public-web I'm not sure I want every conversation indexed either.
The challenge of course is finding your way there. They're not exactly discoverable, and unlike with a job, it's usually through some pretty odd connections that you end up there.
I had plenty of online conversations on Usenet, IRC and email with guys like Abrash and Jez San etc. It was a much smaller community back then and there was no gatekeeping -- everyone's contact info was out there and inbox zero was still achievable.
> The general argument is that if you know you are going to need to release a patch, then you shouldn't be shipping the game in the first place.
Wow that's a chunky improvement over an already fast lang
I have seen applications for MS-DOS, effectively using C as a Macro Assembler, only the data structures and high level logic was C as if Macro Assembler macros.
And still is in VLC. (Okay, maybe not higher, but they do use a crapton of assembly in their decoders, and it does speed them up by a factor of 10 or so today.)
Now beating special use cases, like using vector instructions to parallel process video decoding streams is another matter.
It is no accident that after all the efforts improving Java and .NET JITs for auto-vectorization across various vendors, both platforms now expose SIMD intrinsics as well.
Then there is the whole issue when will they reach other implementations beyond OpenJDK, specially a very important alternative implementation running on many phones across the globe.
Nevertheless the need to explicitly being allowed to write vector code is there.
For scalar code, it was more that the CPUs got better, as out-of-order execution starting with the Pentium Pro made instruction scheduling less important. The original Pentium CPU was an in-order design with two pipes where the second V pipe had significant restrictions, which was harder for compilers to deal with than the PPro/PII and its decoding pattern.
http://www.roylongbottom.org.uk/directdraw%20results.htm
Even the oldest S3 VLB cards performed 8 bit copies 3-4x faster than CPU. Pretty much every VGA chipset from around 1993-94 onward had 2D accelerator, most popular were IBM 8514 derived like from S3 or ATI.
Not sure why they do this, but this even leaves all code as RWX (readable, writable and executable) which is highly insecure.
Not sure if all was true but very fascinating. I think there is a certain character in programmers who went through the fire and storm by writing softwares in assembly language for non trivial CPUs (like Pentium and up) that is unique.
https://www.youtube.com/watch?v=t2kdKB18c7I&t=332s
We were just coming out of the age of assembler. The background blitting is all assembler, but the characters are Direct3D. When I put the 3D engine in there it was a 3D software renderer I had written when I was 13 in C++ and x86 and I just pasted it into the game engine, but I think we took the software renderer out and just used Direct3D's renderer. GPUs were just coming onto the market, and I think the hope was that it would get a boost from a GPU, although I don't remember ever testing it on one. (I do remember going to gaming expos and the card manufacturers would just hand out GPUs to every dev that went to their booths...)
AMA.
OOO maybe this is my chance to figure out why the newest "definitive addition" runs so much worse in Wine.
Fun little format to mess with if you find the docs for it - surprisingly not that difficult to implement (there used to be a wiki with the spec on it, might be gone now?)