So I have been thinking about doing a sega genesis back port of undertale and have come to a crossroad of programming it in asm or C. The only arguments I hear are
Which one should I go for, I already know C and I don't have much interest in learning 68k asm
Why is this even a thread?
doesn't mean I wouldn't be willing
Both opinions show a lack of understanding as to why both exist.
Writing in C means more people will be able to gain at least a basic understanding of your code, it also means your code is easier to maintain.
However C also makes alot of assumptions about the way you want to work with the system (such as calling convention, memory layout, register use).
Assembly allows you to optimise things because you are free to violate those assumptions but that also makes it very difficult to maintain your code and can make shooting yourself in the foot very expensive, a fairly minor bugfix may well require a restructure of your entire program.
Sega Genesis had much more complex games than Undertale written in old C compilers. Doesn't even help that you can use asm from C.
You could indeed port Undertale using asm, but:
If you want a contrarian answer... consider writing a FORTH system for Genesis that lets you incrementally rewrite the procedures/words into assembly.
This user is mostly correct. Dont fuck around with assembly unless you have a real need to.
yeah for sure the amount of time someone will spend fucking up register allocations and stack layout etc will be tenfold of their actual algorithm design/testing.
OP use C but learn how your compiler treats the stack, its calling conventions etc, and learn enough about assembler to know the memory map.
Assembly langauge is more flexible than C for defining game objects that will be stored in ROM.
Interrupt routines might actually be easier in ASM depending on the compiler.
And if you're serious, restrict your game design as much as possible, shoot for NES-tier gameplay and maybe you'll actually finish the project.
My biggest inspiration to make a port is cave-story-md (github.com
C is a shitty language and extremely unproductive because almost everything you do is a way of working around some flaw in the language that has no reason besides being what the PDP-11 compiler did. The standards for C are so low that most of these workarounds are enshrined as "the right way" in C, when they they would be downright offensive if suggested to programmers in other languages. An example is using the preprocessor to swap variables by generating a do { } while(0) loop because of some bizarre syntactic mistakes in the C grammar. It's not enough that you have to use the preprocessor as a workaround, you also have to use a workaround for the workaround because a plain block with braces has the wrong "syntax" in C. In Lisp, you can use rotatef to swap variables, or more generally, to rotate the values of places (generalized variables, like an accessor function or an element of an array).
The day after I posted that, C weenies in this thread are using the same arguments against assembly that JavaScript weenies use against C. C compilers also can't use many of the instructions and addressing modes of the 68K architecture. An assembler with good macros (not UNIX as or GNU gas) would be a better choice than C.
I've been confusing my compiler class with this one for a while now. I pull it out any time someone counters my claim that C has no block structure. They're usually under the delusion that {decl stmt} introduces a block with its own local storage, probably because it looks like it does, and because they are C programmers who use lots of globals and wouldn't know what to do with block structure even if they really had it. But because you can jump into the middle of a block, the compiler is forced to allocate all storage on entry to a procedure, not entry to a block. But it's much worse than than because you need to invokethis procedure call before entering the block.Preallocating the storage doesn't help you. I'll almostguarantee you that the answer to the question "what'ssupposed to happen when I do ?" used to be"gee, I don't know, whatever the PDP-11 compiler did." Nowof course, they're trying to rationalize the language afterthe fact. I wonder if some poor bastard has tried to do adenotational semantics for C. It would probably amount to atranslation of the PDP-11 C compiler into lambda calculus.
based
It amazes me that Rollercoaster Tycoon was 99% Assembly.
The runtime alone for a minimal LISP needs several dozen megabits in RAM, the Genesis only had barely a half megabit.
That's rich coming from the most unproductive group on Zig Forums (if not programmers as a whole).
He says, posting from a machine with several billion transistors that can't even do what those old machines could.
Uh have you made a ROM before? You can't use C only asm.
As I understand it, if taking only one logic core into account, and subtracting the legacy CISC encoder/decoder/microcode frontend on top of the internal RISC, Intel/AMD's underlying architecture is supposedly pretty nice.
lmao as long as the linker script is set up right you can do everything in C, even interrupt vectors.
no libc, stdio, stdlib, etc.
Compiled C was commonly used in Genesis games, e.g.:
segaretro.org
Compilers used to suck, and humans could out optimize them, writing assembly made sense for core routines of games that pushed the limits of available hardware - which was expensive.
Today, we have the opposite problem. Hardware has become super cheap, enabling hyperbloated, unreliable software. Compiliars have advanced significantly, and its unlikely that you will be able to out optimize a compiler. Specially if you don't already know C.
Also, assembly can be linked with C. So there is virtually no reason not to start writing in C, outisde of autism as a hobby (cf. MikeOS).
Premature Optimization is the root of all evil.
Also, modern emulators can emulate games consoles faster than game consoles could have ever run. There is no reason to write assembly unless you want the "authentic" sega hacker experience.
Nothing to do with this thread. Get lost.
t. never programmed assembly
what is it with UNIX fags and hating assembly?
Then howcome every time I write some C shit to assembly I get at least 2x or 3x speedup? That's without studying the x86 ISA at all ever. All I know is what the instructions do and lay them out smartly. I must not know enough C :^)
By this reasoning the Unix hater hates Multics, PL/I, and symbolics machines.
well maybe they don't hate it, but they strongly advise against using assembly every time it's mentioned, throwing around hyperbole like "you can't beat the compiler no matter how hard you try"
LOOOOOOL
Cnile LARPers are so easily triggered
kys
How about I kill you instead?
If you knew what modern compilers do, you'd understand why some say that. The real answer is: use asm when you need to; stuff like video encoding/decoding where we're always CPU bound.
t. writes shit assembly
If a bugfix doesn't require the restructuring of an Assembly program, you're writing Assembly like a compiler and there is literally no reason for you to be writing Assembly. Either write Assembly properly or don't write Assembly at all.
Conventional Wisdom says No. You might be write. Make sure you compile with optimizations on, and any special CPU features on (SSE etc.) Write a blog post about it.
I have written assembly. I have written C. I haven't actually tried to write a complex procedure in assembly and compare. Part of why a compiler will out optimize me, is use of performance extensions I haven't ever used.
lmao I bet you haven't memorized every MMX, SSE1, SSE2 instruction.
Exactly what I said in the post. I have never used any of those instructions. I have mostly re-implemented C library functionality for my Architecture class without using extensions like MMX, SSE1, SSE2, AVX, etc.
Not if there's no ABI for the target platform!
Whats funny is they say the opposite when it comes to C. If you're writing in a higher level language they say that no way it's compiler will come close to hand written C code but apparently the C compiler is better than had written assembly. Unix weenies and Cniles are weasels that will say anything to get people to use their pet language.
2/10, C fanboys aren't against higher level PLs, but against stuff like garbage collection, dynamic typing and other runtime costs; especially when such languages pretend to replace C instead of complementing it.
Which is the same kind of argument. They're saying allocating memory by hand is better than letting a language take care of it. The same kind of argument that cniles use when talking about handwriting assembly. They also don't care about stuff that C manages for you lie the stack. 1/10 C response Unix weenie.
If there is no ABI there is no C compiler. You can't call functions without having a function call ABI. If you are able to compile in C on your platform, than an ABI exists.
Of course not it's all about the situa--
What are you on about? These things have their place. I let the operating system clean up my memory sometimes, I'll use tagged unions where appropriate, and of course I'll write brute-force code if I don't feel like writing a proper solution.
Just as C complements assembly.
But sometimes it is better to do it by hand, faggot.
Protip: there's a difference between compilation and runtime.
If garbage collection somehow managed to do its work only running at compile time (say, by adding allocation and deallocation calls to your code), it would be a lot more welcome: of course, that's not going to happen anytime soon as it's a terribly difficult problem.
Rust can do it.
can you stop posting on Zig Forums and go write a garbage collector to understand how you know nothing about memory management?
mix
Are you just mad that your language does not support doing GC at compile time?
Rust lets you elide the malloc and free calls. In exchange you have to cover your code in & and mut and 'a all over the place. It actually takes more work to do this "automatic memory management" then c programmers take to do manual memory management.
Cniles also litter there codebase with &s.
Mutability has nothing to do with this.
Yes, doing it automatically makes the compiler work harder than just having the programmer manually specify it.
For your case you can probably write most of it in C but you will need learn 68k asm no matter what for at least two reasons:
1. You pretty much have to write your interrupt routines in assembly, the timing windows are too tight to trust a compiler.
2. Especially on an old platform like the Genesis, you need to be able to read assembly and constantly read what the compiler generated to keep on top of performance regressions and what code produces the best results on your platform, otherwise you will have no idea why your code is slow.
With those things in mind, I (knowing a bit about the Genesis but having never developed for it) would guess that you could get away with writing a fair bit of an Undertale demake in C. Menus, the field, dialog, no problem. The most questionable part I can think of would be the bullet system in battles. I don't remember how intense (in number of bullets) the fights in Undertale get, but it's basically a particle system and that's one of the classic areas where performance can tank as the number of particles you need to loop over to update and perform collision detection for increases. Again, don't remember much about Undertale, but I would go into writing the bullet manager (or managers, depending on how you implement that) thinking in the back of your head that you might end up needing to rewrite it in assembly further down the line.
Also, unless you use someone else's sound engine (not a bad idea) or run the sound code on the 68000 (waste of cycles) you're going to need to learn Z80 asm anyway for your sound engine. On the bright side, 68000 assembly is one of the nicest architectures to learn and write, you shouldn't feel too much pain when you do need to write it.
This is very cool, thanks for sharing it.
based
unbased
based
unbased
based
knowing c and/or 68k assembly well is step one. You need to learn the platform too. it's not like Sega genesis just has a chunky mode framebuffer you can write pixels to like on modern hardware. It has several graphics modes and sprires, video chip stealing memory and cycles from your main cpu... All of that is controlled by memory mapped IO, but there's lots of registers. I know most of C64 registers by heart, but I'm sure genesis has at least twice as many.
Rust's system isn't as painless nor as easy as C compilation is, but it's certainly something to keep an eye on: I hope to see alternative implementations soon.
Of all the games you could port, you picked the shittiest one.
Assembly is a pain in the ass to start using and still is a pain in the ass once you learn it. Dealing registers definitely when you have a bunch of them is a pain in the ass and dealing with the stack is also a pain in the ass. if you are doing shit with a sega you should probably use assembly because thats the whole meme of programming old consoles like that.
Why not port to Dreamcast instead? Easier architecture and won't have to worry about optimization as much.
...
Why does it have to be either C or ASM?
because
What other language is there that could be used to program hardware this obsoleted?
Even C++ destructors alone can do it, it's not even something as new as Rust.
words.steveklabnik.com
LARPers are pathetic
based and sage negated
Write your own language and compiler faggot.
In C or asm though?
Im not sure, C is not a good language but it's better than other alternatives.
lol at writing a compiler or runtime for a script in ASM. Fuck that. (nb4 MikeOS)
Only reason to exist is to allow for non procedural syntaxes and even that is a stretch (see Carp lang, for example). In general, it's an incredibly complex or underperforming runtime tumor that's very rarely needed these days, with lsan/valgrind making it pretty hard to leak memory and memory pooling dealing with multithreaded allocation problems.
The fox and the well-made type system. Do SML/Hasklel need dynamic typing?
Yes. What is your point?
And you're talking to someone using Tcl with C extensions. Just to keep the faggot with his forced "Cnile" meme away.
Valgrind can only reveal the presence of leaks during a specific execution, it doesn't guarantee that the program doesn't leak nor is it comparable to GC, what are you on about?
By your logic, writing in assembly and then using a dynamic analyzer to detect whether the data from the stack is correctly deallocated is equivalent to using a language whose semantics make sure this always happens, when it's clearly not.
Bringing up experience after showing a deep misunderstanding of the tools at your disposal certainly doesn't help.
You might want to visit a doctor. I fear you're becoming cnile.
I heard that less LARPing might help.
I never said that valgrind/lsan was more than a helping tool.
You say that like there's no link whatsoever. GC's proponent main arguments are the absence of leaks and the ease of not having to explicitely alloc/dealloc.
I never had a leak that wasn't trivial to solve in my entire programming history and I'm not a programming god, I know segfaults as much as everyone. Getting (and keeping) leaks really is the sign you're retarded.
1/10, be more subtle next time.
Are you retarded or something? GC languages may have memory leaks too.
based and lisppilled
What are you implying? I was completely serious.
based
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
I wonder (((why))).
Fuck off moshe.
A lot of these posts seem to be automated!
Looks like some Soros-funded controlled opposition to me.
I smell some satanic fuckery here.
Europeons need to burn in a tar-pit. Disgusting
Yeah, right, and the moon is made of cheese.
