/lounge/ - Lounge

I can't log in right now but please don't click this shit my niggas rofl

Uploaded to archive.org so this doesn't happen again.

https://archive.org/details/astronot_win

>>105227
It's not malware. Do your own research. There's a wikipedia page for this game and youtube trailer for the release: https://www.youtube.com/watch?v=WNjJaB_UbaA

>>105228
>>105227
I mean I guess it could be malware since I didn't make it but I ran it through virustotal and windows defender and I'm playing it right now.

>>105230
what happens when you click "okay"?

>>105231
exits

>>105232
Are you running the exe with the other files in the same directory? I didn't pay for the game. I don't know why it would work for me and not you.

Can someone else confirm whether it's possible to run the game?

>>105232
I've just uploaded my App data to the internet archive Astronot page. Hopefully that will help.

I don't know what else to do. I don't know how the game works.

>>105233
it works after clicking update

>>105236
cont. it was in my C:\Users\YourName\AppData\Roaming\Astronot

directory. That's where my AppData came from.

would've been better for him to make this for C64 instead of Win/Mac. would've sold more, remained much more in circulation/popularity, and could play on handheld devices with a C64 emulator like PSP, android or linux retro handhelds, etc. (not sure about android, looks like jewgle's killing app sideloading)

>>105243
If you're big on decompilation then decompile the game and redo it using a C64 compiler. It would make for a fun project.

>>105246
commodore 64 has an 8-bit 6502 CPU, there is no compiling, 6502 assembly is your only option.

>>105248
I thought the whole point of compiling was to turn high level code into machine code. So wouldn't it be possible to convert C into C64 machine code?

>>105257
I just looked it up and there actually is a cross compiler for C64, but it's not like you can just take a game made for modern hardware and expect it to run on a C64, even if it looks primitive.

>>105248
*6510 not 6502
though 6510 is practically identical to 6502

>>105257
You need to understand that C, under the hood, works under an abstract memory model with specific memory buffers, similar to how Java works under an abstract model of a virtual machine (I'm simplifying, but I don't really care about the internal details of the JVM, not my interest).

"High level" is an arbitrary, relative classification. I was not alive back then but I'd imagine they considered C to be a "high-level" programming language back in the 1980s, and then "low-level" in the 1990s once 32-bit CPUs became the norm in all PCs and video game consoles (not including handhelds) and made no sense to bother with writing games in assembly over C once the overhead from compiled code became imperceptible, and other languages further abstracted from hardware like Java were released and popularized. Today non-compiled and/or garbage-collected languages are considered high-level. Depending who you ask, I suppose assembly would be "super duper low level"?

Anyway, back to the C abstract machine model. The machine code produced by a C compiler requires at minimum the following five 16-bit (2-byte) buffers:
Stack Pointer (SP)
Frame Pointer (FP)
Program Counter (PC)
Working Registers 1 & 2

C was designed for CPUs that have at least five 16-bit registers that can fit these five 16-bit buffers. A register is a temporary memory storage placed inside the CPU for quicker access. It's even faster to access than "CPU cache" introduced in modern CPUs. Read https://stackoverflow.com/questions/10274355/cycles-cost-for-l1-cache-hit-vs-register-on-x86 for more details on that.

The PDP-11 released in 1970, the first CPU that C was designed for, had six 16-bit general purpose registers.
The Intel 8086 released in 1978 had fourteen 16-bit registers, eight of them being general purpose registers, three of them being specialized for SP, FP and PC, and the rest some other specialized registers I don't understand or really care to learn about.
So obviously these CPUs have enough registers to fit the minimum of five 16-bit buffers that are expected by the C abstract memory model.

The 6502 has six specialized registers, five of them being 8-bit (1-byte) with the remaining one being 16-bit (2 bytes) specialized for the Program Counter (PC). Do you see the problem? Where are you going to fit the other four 16-bit buffers that are expected by the C abstract memory model?

How do C cross-compilers like cc65 for 6502 CPUs (as seen in C64, NES, Atari 2600, PC Engine and others) get around this? They place these 16-bit buffers in RAM instead of a CPU register. What's the problem with that? It takes way longer for the CPU to access those buffers, not only by the extra distance but also extra instructions are required to be produced by the compiler to be able to emulate those 16-bit buffers in RAM as 16-bit registers. There are only so many instructions per second (IPS) a CPU can process.

Read more about instructions per second (IPS) here:
https://www.pcmag.com/encyclopedia/term/instructions-per-second
https://computer.fandom.com/wiki/Instructions_per_second
https://en.wikipedia.org/wiki/Instructions_per_second

Now see this performance benchmark comparing code on the C64, C version (cc65) vs. inline assembly to put this rest:
https://goabq.org/c64/c64-speed-comparison.html

It's an impressive experiment, but not practical for writing games with.

When writing with assembly, at least on the 6502, there is no "frame pointer" (FP) you have to worry about, and your stack pointer (SP) does not have to be 16-bits as demanded by C, your working register equivalents on the 6502 do not have to be 16-bit (they are instead three specialized 8-bit registers).

You can read more about registers and their various types and sizes here: https://www.totalphase.com/blog/2023/05/what-is-register-in-cpu-how-does-it-work/

>>105259
The game is simple enough it could be rewritten in 6502 assembly and run at full NTSC (60 FPS) speed on a C64.
It's not more complex than Sam's Journey.

>>105259
Here is also Super Mario Bros for NES converted for the C64 from the NES ROM. It's not even hand optimized as well as it could be. For example the collision detection code between the player and enemies could be simplified a bit so it doesn't slow down as much when there are more enemies on screen. The 6502 on the NES runs at a higher clock speed than on the C64, the Nintendo devs had more headroom to work with.

One of the top comments (though he's wrong about compiling, there's no compiling here):
>For those of you saying this is pushing the hardware to the limit, it isn't. The reason for the slowdown is because this is compiled straight from the nes rom, and due to the slower cpu of the c64 this is the result. Stuff like Sam's journey shows more of what the c64 is capable of but this is just amazing due to what it is actually accomplishing from coding.