If you’ve written 500k lines of code you were surely pretty confident about your decision.
this post was submitted on 17 Oct 2024
1005 points (99.0% liked)
RetroGaming
19338 readers
1642 users here now
Vintage gaming community.
Rules:
- Be kind.
- No spam or soliciting for money.
- No racism or other bigotry allowed.
- Obviously nothing illegal.
If you see these please report them.
founded 1 year ago
MODERATORS
You sweet summer child...
I’m a developer, I don’t just continue doing things for years if it doesn’t make sense.
(If I’m the one making the decisions)
I have seen Devs do things for many years that make no sense
programmers just not a uniform bunch. not all of them blockchain grifters. fancy that.
Roller coaster Tycoon is one of a lifetime game.
Now everything is electron or react shit. Gone are the times of downloading fully featured software under 10mb.
I don't think old=good is a good mentality though, lot of people seem to have it
All the old software I know and use is exceptionally good, however I've heard about and chosen to use it because it's survived the test of time (also because it's still actively maintained and has had thousands of bug fixes over the years)
Vscode and obsidian are pretty good and they're electron, discord's alright, pretty sure steam uses some kind of web wrapper as well.
Real issue is electron is very accessible to inexperienced developers and easy to do badly, but I imagine people back in the old Unix days got an equal amount of shit bloated software
Discord is garbage software lmao. Has been from the beginning. I can't stand using it.
Fun quote from an interview with Chris Sawyer:
Latterly the machine code came back to haunt us when the decision was made to re-launch the original game on mobile platforms as RollerCoaster Tycoon Classic a few years ago, and it took several years and a small team of programmers to re-write the entire game in C++. It actually took a lot longer to re-write the game in C++ than it took me to write the original machine code version 20 years earlier.
Well worth it. The mobile version is amazing, that is to say, almost exactly the same as the original.
Further proof C++ is a pita
#include <iostream> // because writing to the console is not included by default.
int main()
{
std::cout << "C++ is simple and fun ... you cretin";
return 0;
}
I had a machine language course in uni, parallel with a C++ course. Not a fun semester to be my wife, or a relative of any of my classmates. Best case our brains were in C++ mode, worst case you needed an assembler to understand us.
And yes I know my code format will piss people off, I don't care, it's the way I write when other less informed people don't force me to conform to their BS "Teh oPeNiNg bracket shouwd bwee on teh sam line ass teh declawation"
But the modern OpenRCT, written in an actual language, is better in every way.
Probably not as optimized though.
RCT could run on a toaster from the 90's (ok, maybe early 2000's) and looked amazing for the time.
OpenRCT can run on a toaster from the 2010's and looks great because of the timeless art style of the original.
It's still an incredible feat, though!
You are very unlikely to write assembly that is more optimized than what a modern compiler could produce for anything longer than a trivial program. I don't know if it made sense at the time of the original RCT, but OpenRCT would definitely not benefit from being written in assembly.
I feel like that's only true if I was asked to "write the assembly for this c++ program." If I'm actually implementing something big in assembly, I'm not going to do 90% of the craziness someone might be tempted to do in c++. Something that is super easy in c++ doesn't mean it's easy for the CPU. Writing assembly, I'm going to do what's easy for the CPU (and efficient) because, now, I'm in the same domain.
The bottom line is cranking up the optimization level can get you a 2-5x win. Using memory efficiently can give you a 10-100x win.
- Programming was never meant to be abstract so far from the hardware.
- 640k is enough ram for everybody.
- The come with names like rust, typescript, go, and python. Names thought up by imbeciles.
- Dev environments, environmental variables, build and make scripts, and macros, from the minds of the utter deranged.
They have played us for fools
I dabbled with making a fairly complex program for a microcontroller the other day and quickly hit the stack limit for a simple object.
It wasn't so much that it was a large object, but to provide flexibility I was amazed how fast I filled the memory.
I've done heaps with memory managed languages in the past but shit as soon as I had to think about what I was doing under the hood everything got hard af.
So serious question - does anyone have any good resources for a competent programmer, but with no clue whatsoever how to manage memory in a microcontroller space and avoid fragmentation etc?
I got it to work but I'm sure I did shit job and want to be better at it.
The best book I've ever bought on programming, and the second best book I bought for a class in uni, was https://dl.acm.org/doi/book/10.5555/1824214 it may be worth checking out on libgen and buy if it suits your needs.
Whenever I do low-level programming on the AVR architecture, I'll make a memory map. As in I'll map out where I'll put what. It may not be suitable for more complex programs, but it does the job for me. And it has enabled teamwork in assembly in the past.
If you want to work in a language that doesn't offer memory management, but manually mapping memory isn't feasible either, how about building your own memory management? Or perhaps use an RTOS? I've used freeRTOS before on various arm-based micros, and it does take a bit to get started, but after that it's easy sailing.
Sorry for the following tangent, all semi intelligent content in this comment is found above this line.
BTW I tried CoOS once, I wouldn't recommend it... OK it was 12 years ago, I can't remember exactly what was wrong other than the documentation was crap, but I don't need to remember why to hold a grudge.
try writing it it in Assembly
Small error, game crashes and takes whole PC with it burning a hole in the ground.
I love Roller Coaster Tycoon. It's absolutely crazy how he managed to write a game in a way many wouldn't even attempt even in those days, but it's not just a technical feat, it's a creative masterpiece that's still an absolute blast to play.
It still blows my mind how smoothly it gives the illusion of 3D and physics, yet it can run on almost anything.
OpenRCT brings a lot of quality of life and is often the recommended way to play today, but the original RCT will always deserve a spot on any "Best Games of All Time" list.
load more comments
(1 replies)
Your game will actually likely be more efficient if written in C. The gcc compiler has become ridiculously optimized and probably knows more tricks than you do.
Especially these days. Current-gen x86 architecture has all kinds of insane optimizations and special instruction sets that the Pentium I never had (e.g. SSE). You really do need a higher-level compiler at your back to make the most of it these days. And even then, there are cases where you have to resort to inline ASM or processor-specific intrinsics to optimize to the level that Roller Coaster Tycoon is/was. (original system specs)
I might be wrong, but doesn't SSE require you to explicitly use it in C/C++? Laying out your data as arrays and specifically calling the SIMD operations on them?
There’s absolutely nothing you can do in C that you can’t also do in assembly. Because assembly is just the bunch of bits that the compiler generates.
That said, you’d have to be insane to write a game featuring SIMD instructions these days in assembly.
load more comments
(4 replies)
petah please what's this mean
The game Roller Coaster Tycoon was famously hand written in raw CPU instructions (called assembly language). It’s only one step removed from writing literal ones and zeros. Normally computers are programmed using a human-friendly language which is then “compiled” into CPU instructions so that the humans don’t have to deal with the tedium and complication of writing CPU instructions.
To further emphasize this, I had an assembly course in university. During my first lab, the instructor told us to add a comment explaining what every line of assembly code did, because if we didn't, we would forget what we wrote.
I listened to his advice, but one day I was in a rush, so I didn't leave comments. I swear, I looked away from the computer for like 2 minutes, looked back, and had no idea what I wrote. I basically had to redo my work.
It is not that much better than reading 1s and 0s. In fact in that course, we spent a lot of time converting 1s and 0s (by hand) to assembly and back. Got pretty good at it, would never even think of writing a game. I would literally rather create my own compiler and programming language than write a game in assembly.
I'm probably completely insane and deranged, but I actually like assembly. With decent reverse engineering software like Ghidra, it's not terribly difficult to understand the intent and operation of isolated functions.
Mnemonics for the amd64 AVX extensions can go the fuck right off a bridge, though. VCVTTPS2UQQ might as well be my hands rolling across a keyboard, not a truncated conversation from packed single precision floats into packed unsigned quadword integers.
Ah yes, there was this guy in our tech school class that used to code golf in assembly. Was a crack in math and analytics too, which might explain it somewhat. Well, everyone is different i guess.
I had a course in uni that taught us assembler on z/os. My advisor told me most students fail the course on the first try because it was so tough and my Prof for that course said if any of us managed to get at least a B in the course, he'd write us a rec letter for graduate school. That course was the most difficult and most fun I've ever had. I learned how to properly use registers to store my values for calculations, I learned how to use subroutines. Earned myself that B and went on to take the follow up course which was COBOL. You're not crazy, I yearn to go back to doing low level programming, I'm mostly doing ruby for my job but I think my heart never left assembler hahaha
thanks petah
To send the point home even more, this is how in python you make a line of text display:
print("Hello World")
This is the same thing, in assembly (According to a blog I found. I can't read this. I am not build better.)
org 0x100 ; .com files always start 256 bytes into the segment
; int 21h is going to want...
mov dx, msg ; the address of or message in dx
mov ah, 9 ; ah=9 - "print string" sub-function
int 0x21 ; call dos services
mov ah, 0x4c ; "terminate program" sub-function
int 0x21 ; call dos services
msg db 'Hello, World!', 0x0d, 0x0a, '$' ; $-terminated message
But python turns that cute little line up top, into that mess at the bottom.
I like python. Python is cute. Anyone can read python.
That assembly is for a DOS application. It would be more verbose for a modern Linux or Win32 application and probably require a linker script.
But python turns that cute little line up top, into that mess at the bottom.
Technically, not quite. Python is interpreted, so it's more like "call the print function with this string parameter" gets fed into another program, which calls it's own functions to make it happen.
load more comments
(1 replies)
I don't know if everyone gets the reference: RollerCoaster Tycoon is in fact writing mostly in assembly to use the hardware more efficiently
It also makes it really portable which is a big part of why all the ports to modern systems are so close to the original. Obligatory OpenRCT2 shoutout.
edit: This is not entirely correct, I was mistaken about my understanding of some things. Still check out openrct2
OpenRCT2 ditched assembly tho. They wrote it entirely in C++.
Sorry, two separate thoughts. Wasn’t saying open RCT used assembly just wanting to shout out the project.
Writing it in assembly would make it pretty much the opposite of portable (not accounting for emulation), since you are directly giving instructions to a specific hardware and OS.
load more comments
(3 replies)
load more comments
(5 replies)
view more: next ›