/tech/ - Technology★

>>1043023 (OP)

>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?

>>1043025

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.

>>1043026

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:

>You do not know such assembly yet. Chances are you wouldn't know how to outsmart the compiler if you have not mastered the language.

>Programming a game in assembly nowadays is pure autism.

>You will probably give up halfway in if you program it in C. If you have to learn a new language first, you will drop it a quarter in.

>Undertale's processing power requirements are pretty much null. I can imagine it being even less resource intensive than your average platformer.

If you want a contrarian answer... consider writing a FORTH system for Genesis that lets you incrementally rewrite the procedures/words into assembly.

>>1043028

This anon is mostly correct. Dont fuck around with assembly unless you have a real need to.

>>1043053

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.

>>1043066

>>1043031

>>1043053

My biggest inspiration to make a port is cave-story-md (https://github.com/andwn/cave-story-md/), they seem to use a mix of most C and some asm, so would it be unavoidable to use asm in some cases?

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).

>A lot of software was written in assembly which C weenies look down on for being "less safe", but it still doesn't suffer from all these bugs and exploits. The "design" of C makes it harder to prevent errors than assembly language. That's why Linux needs 15,600 "programmers" and still can't get rid of the OOM killer.

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 invoke
this procedure call before entering the block.
Preallocating the storage doesn't help you.  I'll almost
guarantee you that the answer to the question "what's
supposed to happen when I do <the thing above>?" used to be
"gee, I don't know, whatever the PDP-11 compiler did."  Now
of course, they're trying to rationalize the language after
the fact.  I wonder if some poor bastard has tried to do a
denotational semantics for C.  It would probably amount to a
translation of the PDP-11 C compiler into lambda calculus.

>>1043074

based

>>1043053

It amazes me that Rollercoaster Tycoon was 99% Assembly.

>>1043074

>Lisp

The runtime alone for a minimal LISP needs several dozen megabits in RAM, the Genesis only had barely a half megabit.

<muh hardware-accelerated GC

Stack machines implementing LISP's GC runtime in hardware were just as bloated as their software runtimes, with the TI MegaChip requiring well over 500k transistors, enough for fourteen of the Genesis' M68k CPU.

>>1043074

>C

>extremely unproductive

That's rich coming from the most unproductive group on /tech/ (if not programmers as a whole).

>>1043083

>muh 500k transistors

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.

>>1043098

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.

https://github.com/andwn/marsdev/releases

https://www.romhacking.net/documents/277/

>>1043098

Compiled C was commonly used in Genesis games, e.g.:

https://segaretro.org/Sierra_68000_C_Compiler

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.

>>1043074

Nothing to do with this thread. Get lost.

>>1043028

>a fairly minor bugfix may well require a restructure of your entire program.

t. never programmed assembly

what is it with UNIX fags and hating assembly?

>>1043337

>its unlikely that you will be able to out optimize a compiler.

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 :^)

>>1043359

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"

>>1043087

>That's rich coming from the most unproductive group on /tech/

LOOOOOOL

Cnile LARPers are so easily triggered

>>1043343

kys

>>1043402

How about I kill you instead?

>>1043385

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.

>>1043347

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.

>>1043356

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.

>>1043430

>he can't perform data-flow analysis, strength reduction, inlining, partial evaluation, and complex register allocation and instruction selection with peephole optimization in his head in under 30 seconds

lmao I bet you haven't memorized every MMX, SSE1, SSE2 instruction.

>>1043462

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.

>>1043160

Not if there's no ABI for the target platform!

>>1043385

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.

>>1043632

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.

>>1043634

> against stuff like garbage collection

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.

>>1043519

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.

>>1043634

>C fanboys aren't against higher level PLs,

Of course not it's all about the situa--

>but against stuff like garbage collection, dynamic typing and other runtime costs

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.

>especially when such languages pretend to replace C instead of complementing it.

Just as C complements assembly.

>>1043645

>They're saying allocating memory by hand is better than letting a language take care of it

But sometimes it is better to do it by hand, faggot.

>>1043645

>Which is the same kind of argument.

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.

>>1043672

>that's not going to happen anytime soon as it's a terribly difficult problem

Rust can do it.

>>1043680

can you stop posting on /tech/ and go write a garbage collector to understand how you know nothing about memory management?

mix

>>1043685

Are you just mad that your language does not support doing GC at compile time?

>>1043680

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.

>>1043692

>&

Cniles also litter there codebase with &s.

>mut

Mutability has nothing to do with this.

>It actually takes more work to do 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.

>>1043068

This is very cool, thanks for sharing it.

>>1043680

based

>>1043685

unbased

>>1043687

based

>>1043692

unbased

>>1043693

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.

>>1043680

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.

>>1043023 (OP)

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.

>>1043951

>not the 3DO Interactive Multiplayer

>>1043023 (OP)

Why does it have to be either C or ASM?

>>1044327

because

>sega genesis

What other language is there that could be used to program hardware this obsoleted?

>>1043685

Even C++ destructors alone can do it, it's not even something as new as Rust.

>>1043685

https://words.steveklabnik.com/borrow-checking-escape-analysis-and-the-generational-hypothesis

>getting BTFO by Steve Klabnik

LARPers are pathetic

>>1044330

based and sage negated

>>1043023 (OP)

Write your own language and compiler faggot.

>>1044336

In C or asm though?

>>1044337

Im not sure, C is not a good language but it's better than other alternatives.

>>1044364

lol at writing a compiler or runtime for a script in ASM. Fuck that. (nb4 MikeOS)

>>1043655

>What are you on about? These things have their place

>garbage collection

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.

>dynamic typing

The fox and the well-made type system. Do SML/Hasklel need dynamic typing?

>Just as C complements assembly.

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.

>>1044410

>valgrind

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.

>>1044410

>hurr durr valgrind make C/C++ perfectly safe

You might want to visit a doctor. I fear you're becoming cnile.

I heard that less LARPing might help.

>>1044421

>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

I never said that valgrind/lsan was more than a helping tool.

>no comparable to GC

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.

>>1044432

1/10, be more subtle next time.

>>1044421

>it doesn't guarantee that the program doesn't leak nor is it comparable to GC

Are you retarded or something? GC languages may have memory leaks too.

>>1043074

based and lisppilled

>>1044447

>1/10, be more subtle next time.

What are you implying? I was completely serious.

>>1044459

based

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

I wonder (((why))).

I smell some satanic fuckery here.