[ / / / / / / / / / / / / / ] [ dir / baphomet / caco / choroy / christ / dbv / dempart / gfl / leandro ]

/tech/ - Technology

Winner of the 83rd Attention-Hungry Games
/strek/ - Remove Hasperat

May 2019 - 8chan Transparency Report
Email
Comment *
Verification *
File
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Flag
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 3 per post.


File: 674e909c80bf823⋯.jpeg (433.28 KB, 1093x1600, 1093:1600, download.jpeg)

 No.1043023

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

>The compiler knows better than you, use C

>you can do better low level optimizations on low power platforms, use asm

Which one should I go for, I already know C and I don't have much interest in learning 68k asm

 No.1043025

>>1043023

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


 No.1043026

>>1043025

doesn't mean I wouldn't be willing


 No.1043028

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.


 No.1043031

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


 No.1043049

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


 No.1043053

>>1043028

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


 No.1043066

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


 No.1043068

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


 No.1043074

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.


 No.1043076


 No.1043082

>>1043053

It amazes me that Rollercoaster Tycoon was 99% Assembly.


 No.1043083

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


 No.1043087

>>1043074

>C

>extremely unproductive

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


 No.1043094

>>1043083

>muh 500k transistors

He says, posting from a machine with several billion transistors that can't even do what those old machines could.


 No.1043098

Uh have you made a ROM before? You can't use C only asm.


 No.1043153

File: 8f2ddcb1fd2e9ab⋯.jpg (42.77 KB, 650x348, 325:174, amd_jaguar_core_floor_plan.jpg)

>>1043094

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.


 No.1043160

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


 No.1043161


 No.1043183

>>1043098

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

https://segaretro.org/Sierra_68000_C_Compiler


 No.1043337

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.


 No.1043343

>>1043074

Nothing to do with this thread. Get lost.


 No.1043347

>>1043028

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

t. never programmed assembly


 No.1043348

what is it with UNIX fags and hating assembly?


 No.1043356

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


 No.1043359

File: 316dbadd96ff965⋯.gif (289.11 KB, 400x471, 400:471, 1448094391314.gif)

>>1043348

>Unixfags hate assembly

>if you don't use something all the time you must hate it

By this reasoning the Unix hater hates Multics, PL/I, and symbolics machines.


 No.1043385

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


 No.1043402

>>1043087

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

LOOOOOOL

Cnile LARPers are so easily triggered

>>1043343

kys


 No.1043408

>>1043402

How about I kill you instead?


 No.1043413

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


 No.1043415

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


 No.1043430

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


 No.1043462

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


 No.1043467

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


 No.1043519

>>1043160

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


 No.1043632

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


 No.1043634

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


 No.1043645

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


 No.1043651

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


 No.1043655

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


 No.1043659

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


 No.1043672

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


 No.1043680

>>1043672

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

Rust can do it.


 No.1043685

>>1043680

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


 No.1043686

mix


 No.1043687

>>1043685

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


 No.1043692

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


 No.1043693

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


 No.1043696

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.


 No.1043789


 No.1043822

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.


 No.1043873

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


 No.1043885

>>1043023

Of all the games you could port, you picked the shittiest one.


 No.1043899

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.


 No.1043951

Why not port to Dreamcast instead? Easier architecture and won't have to worry about optimization as much.


 No.1043956

>>1043951

>not the 3DO Interactive Multiplayer


 No.1044327

>>1043023

Why does it have to be either C or ASM?


 No.1044329

>>1044327

because

>sega genesis

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


 No.1044330

>>1043685

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


 No.1044331


 No.1044336

>>1043023

Write your own language and compiler faggot.


 No.1044337

>>1044336

In C or asm though?


 No.1044364

>>1044337

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


 No.1044378

>>1044364

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


 No.1044410

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


 No.1044421

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


 No.1044432

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


 No.1044447

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


 No.1044455

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


 No.1044459

>>1043074

based and lisppilled


 No.1044464

>>1044447

>1/10, be more subtle next time.

What are you implying? I was completely serious.

>>1044459

based


 No.1053582

HAPAS ARE SUPERIOR TO WHITES


 No.1055011

HAPAS ARE SUPERIOR TO WHITES


 No.1055035

HAPAS ARE SUPERIOR TO WHITES


 No.1056295

I wonder (((why))).


 No.1056851

I smell some satanic fuckery here.




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / baphomet / caco / choroy / christ / dbv / dempart / gfl / leandro ]