75 replies to this topic

[Hodgman]

Not exactly a "lack of control", but more hassle with control. HLLs like C++ and Java COULD MAYBE get as low to the point of controlling bits, nibbles and bytes, storing and such, but it's going to not be done in the same manner as Assembly.

You're right, it won't be the same. It will be easier, faster, and much more understandable when written in C++. I manipulate bits and bytes and low-level hardware devices every day in C++ --- if I had to do the same in assembly, we'd never have enough time to ship a game!

Post an example of asm and C++ bit manipulation to show that the asm version is simpler plox.

[FelixK15]

I can make any job complete as long as I have an OS and machine code. I can directly access hardware myself, I don't need "third-party" crap except what I already came with in my licensed-end user agreement with my computer.

I don't need any damned "tools"... Do you people understand that? Tools are not for me!

okay then tell me how long you need to finish your projects?

It will be easier, faster, and much more understandable when written in C++.

Maybe easier and more understandable but not (always) faster.

I remember a section in a book about Assembler I bought a few months ago. The author demonstrated the rendering and physical calculations of 2 obsticales in OpenGL. He wrote the same application in c++ and assembler.

And now guess which one was faster. (And also more unreadable )

[AndyWonHarglesis]

I'm not angry -- I'm trying to emphasise how fucking awesome that bridge is! It's ridiculously fucking cool!

Seriously, how many bridges have you built? And by that I mean how many games have you finished?

You are angry. Stop kidding yourself...

I have made several games in high-level languages and hated it. That's why I'm moving lower.

Using either C++ or assembly has no impact on the amount of memory your game ends up using. Every PS3 game has to fit into 256MB of RAM, and I assure you that they're generally written in C or C++, but never in 100% assembly.

Whoever or wherever you got that information from is totally false. Final Fantasy 13 for PS3 requires 2GB of RAM, not 256MB. You really have no knowledge, and there's sources that back up my claims.

If I posted the equivalent code in C++, it would take 10 seconds for you to know exactly what it does. Q.E.D. 0's and 1's are 1440 times less readable than C++ (4hrs*60mins*40secs / 10secs). Look it up.

Performance > readability. What you can read easier is great for understanding, but what rolls is what is the result of this "readability", not how well it was "read".

Is this some kind of book we need to read here?

This is what we're all thinking! You're spouting nonsense and ignoring reason. Why should anyone bother to listen, unless they enjoy feeding trolls?

You really have no evidence to prove a single thing you say to be valid, yet countless sources can back up what I say. Working in Assembly DOES and WILL grant better access that C++ or ANY other higher language or API and WILL have access to make faster programs. It is a known fact, just not to people who are misinformed of technology like you.

[AndyWonHarglesis]

You're right, it won't be the same. It will be easier, faster, and much more understandable when written in C++. I manipulate bits and bytes and low-level hardware devices every day in C++ --- if I had to do the same in assembly, we'd never have enough time to ship a game!

Post an example of asm and C++ bit manipulation to show that the asm version is simpler plox.

You seem to be convinced that high-level can act as low-level, but in reality that's not possible. Are you knowledgeable in anything other than high level languages? Please do tell...

Anyways, however well that high-level languages can do what low-level ones can, the truth is that it's just not 100% possible. C++ is not that bad, but Assembly has more power than C++ does being that Assembly is right above the lowest hardware of them all: processor.

Where is C++, again? Oh, right!

>> C++ <<



^^^^ All the way up there! ^^^^

How's the view? Need a longer stick?

[BitMaster]

Using either C++ or assembly has no impact on the amount of memory your game ends up using. Every PS3 game has to fit into 256MB of RAM, and I assure you that they're generally written in C or C++, but never in 100% assembly.

Whoever or wherever you got that information from is totally false. Final Fantasy 13 for PS3 requires 2GB of RAM, not 256MB. You really have no knowledge, and there's sources that back up my claims.

According to Wikipedia the Playstation 3 does only have 256MB of system memory and 256MB of video memory. Unless you have a more reliable system information about the PS3 (in this case, a proper reference would be required) with different information we just have another sample of "I like to talk but I have no clue what I talk about". Of course that should not exactly be a surprise to anyone.

[Hodgman]

I have made several games in high-level languages and hated it.

Links or it didn't happen.

Whoever or wherever you got that information from is totally false. Final Fantasy 13 for PS3 requires 2GB of RAM, not 256MB. You really have no knowledge, and there's sources that back up my claims.

I got my information from the PS3 SDK sitting in front of me that says that the PS3 only has 256MB of RAM in it's main bank. It's physically impossible for a PS3 game to use 2GB of RAM when the machine doesn't have that much!!

You really have no evidence to prove a single thing you say to be valid, yet countless sources can back up what I say.

Crack out the sources then! Show us that your hand-written x86 code is reliably faster than MSVC's compiler! Show us that it's good practice to write ASM. Show us that code readability has no value. Show us that playstations have 2GB of ram in them.
We're all waiting for you to prove your nonsense claims.

You are angry. Stop kidding yourself

I'm too busy laughing at an arrogant emo kid to be angry right now, sorry.

Post an example of asm and C++ bit manipulation to show that the asm version is simpler plox.

You seem to be convinced that high-level can act as low-level, but in reality that's not possible.

Seeing I do bit manipulation and talk to hardware devices from C++ it seems pretty low-level. I could be wrong though... Ever heard of an intrinsic function? No?
Also, you didn't post an example to prove your nonsense claim...

[lpcstr]

You are angry. Stop kidding yourself...

You are clearly trolling. This is a forum for logical discussion. Nobody should be angry and you shouldn't be trying to provoke people, which you are.

Final Fantasy 13 for PS3 requires 2GB of RAM, not 256MB. You really have no knowledge, and there's sources that back up my claims.

Look who's talking. You haven't backed up one claim this entire time. FYI, the PS3 doesn't have 2GB of ram. It has 256MB, like he said. You can look it up for yourself.

You either made a mistake about the PS3s memory configuration, or you don't even comprehend the difference between RAM and the storage of asset files like models and textures.

Performance > readability.

No it's not. If you knew anything about programming, you'd at least know that. Nobody on this site is ever going to work for the same company as you because they aren't going to want to fix your horrible, unreadable code.That assumes that there is some crazy hiring manager out there that would let somebody with your claims even make it to a first interview.

[AndyWonHarglesis]

okay then tell me how long you need to finish your projects?

I made a snake game in Assembly in about two weeks. I used no third-party APIs, no high-level control, nothing. I'm very proud of the game.

All I needed was Assembly and Windows OS for some slightly "higher" graphics control.

Now, let's compare it to a C++ snake game ...

1.C++ snake game probably has a higher tendency of getting stuck, having a bug due to complicating high-level codes/functions, eating up more RAM and putting your CPU through torture.

2.C++ snake game needed endless additional files for additional support for keyboard input, timing, an input output stream(crappy one), etc.

3.C++ snake game probably doesn't perform in the exact, 100% way you'd expect it to and although the code is more readable it isn't more efficient.

Now, let's change it to Assembly's snake game ...

1.Assembly's snake game has almost no possibility of getting stuck due to low-level access of hardware, controls and operating at a bit-level way better than you would in C++ or other high-level languages.

2.Assembly's snake game doesn't need thousands of DLL files, .lib files, .h files, .win files, etc. All of that can be optimized directly and requires less storage of shit! Plus, files can be written all into one source and controlled through one executable output rather than having tons of damned files roaming all over endless directories!

3.Assembly's snake game is not only going to be faster, will have less likelihood of acting up of failing to catch input, but will perform more smooth, efficient and will require less complication and waste of space and will have EVERYTHING put to use rather than tons of crappy files that just "sit there in case I need them".

Assembly > high-level.

[Tachikoma]

I made a snake game in Assembly in about two weeks. I used no third-party APIs, no high-level control, nothing. I'm very proud of the game.

Links or it didn't happen.

[FelixK15]

I'm stopping replying to this thread NOW. Too much aggression.

[lpcstr]

I made a snake game in Assembly in about two weeks. I used no third-party APIs, no high-level control, nothing. I'm very proud of the game.

grats

All I needed was Assembly and Windows OS for some slightly "higher" graphics control.

Win32 IS a 3rd party api, since you didn't write it. Maybe you should create a bootable version of your snake clone that sits in your MBR and draws by accessing video memory.

1.C++ snake game probably has a higher tendency of getting stuck, having a bug due to complicating high-level codes/functions, eating up more RAM and putting your CPU through torture.

false. citation needed.

2.C++ snake game needed endless additional files for additional support for keyboard input, timing, an input output stream(crappy one), etc.

false. C++ has access to the same Win32 API you used from assembly, though the option of using better, cross-platform compatible APIs is a +1 for C++.

3.C++ snake game probably doesn't perform in the exact, 100% way you'd expect it to and although the code is more readable it isn't more efficient.

false. citation needed. C++ isn't a quantum language. It behaves in predictable ways. Maybe you are an unpredictable programmer.

1.Assembly's snake game has almost no possibility of getting stuck due to low-level access of hardware, controls and operating at a bit-level way better than you would in C++ or other high-level languages.

false. citation needed. you can create buggy code in any language, especially assembly.

2.Assembly's snake game doesn't need thousands of DLL files, .lib files, .h files, .win files, etc. All of that can be optimized directly and requires less storage of shit! Plus, files can be written all into one source and controlled through one executable output rather than having tons of damned files roaming all over endless directories!

false. citation needed. As already stated, you aren't required to use 1000s of DLLs just because you are programming in C++.

3.Assembly's snake game is not only going to be faster, will have less likelihood of acting up of failing to catch input, but will perform more smooth, efficient and will require less complication and waste of space and will have EVERYTHING put to use rather than tons of crappy files that just "sit there in case I need them".

If your snake game is suffering performance penalties it's because you are a horrible programmer. I could write a snake game in BASIC and run the interpreter inside a virtual machine and it still would not come close to having input lag or performance problems.

[AndyWonHarglesis]

Links or it didn't happen.

I can show a video of it. But I can't give links because to upload it online requires permission from the assembler I used.

Want to see the videos? I can show VERY convincing videos, 100% proof.

[lpcstr]

But I can't give links because to upload it online requires permission from the assembler I used.

WHAT?! That's insane. I don't believe you.

Then post the assembly code... or do you require permission from the text editor you used?

[BitMaster]

So, anyone want to bet whether Andy will just quietly sneak out of this thread, change the topic or show us some code which, 15 minutes later, will turn out to be from an Assembler equivalent of deviant art?

[AndyWonHarglesis]

WHAT?! That's insane. I don't believe you.

Then post the assembly code... or do you require permission from the text editor you used?

Well, you better believe it. The assembler I use is an old one called FASM-T4. It's only available on XENIO-12 BEST OS. It's a 16bit operating system from 2004(not professionally made).

And I could post the source code, but it's about 38,214 lines. Is there a character limit here?

So, anyone want to bet whether Andy will just quietly sneak out of this thread, change the topic or show us some code which, 15 minutes later, will turn out to be from an Assembler equivalent of deviant art?

I'm not going nowhere.

You want the code? I can post it online and give the link to it.

Though, REMEMBER, for it to work, it has to be on a 16bit operating system and you have to the use the FASM-T4 assembler and it's only available on XENIO-12 BEST OS. It can be ported, if you wish, but I'd need to know the OS and that would take extra time/work, if possible...

[szecs]

Come on you guys! How many times you'll fall for this trolling again, huh?
He/She obviously doesn't know what he/she is talking about and obviously haven't made a snake game, I made one, and it didn't have "thousands of DLL files, .lib files, .h files, .win files, etc". It was one .c file. Okay, I dared to use GDI to draw the stuff. And no "tons of damned files roaming all over endless directories". It was one little exe. Its obvious that he/she doesn't know shit.

Anyway, comparing a game that simple easy-as-pie is pretty much useless. It's obvious, that the OP doesn't know shit about game development.

OP, please show us an assembly snippet of a rasterizer (with texture mapping) you wrote!

[lpcstr]

Well, you better believe it. The assembler I use is an old one called FASM-T4. It's only available on XENIO-12 BEST OS. It's a 16bit operating system from 2004.

And I could post the source code, but it's about 38,214 lines. Is there a character limit here?

Even better! Assembly nobody could possibly assemble and executables nobody could ever execute!

It really works out well for these people when you just have to take their word for it. Don't bother posting a video, we've seen what a snake game looks like before. Probably decades ago, on monochrome screens.

As for the code, who here is going to be interested in 16-bit ASM for a dead OS (that I can't even find proof of its existence)? Not us. Not employers. Nobody.

[BitMaster]

Come on you guys! How many times you'll fall for this trolling again, huh?

Well, a mod could just ban him/her/it for obvious trolling. But in the meantime, I do have a few minutes now and again when my test cases are running through.

[AndyWonHarglesis]

As for the code, who he is going to be interested in 16-bit ASM for a dead OS? Not us. Not employers. Nobody.

I could give a damn about what interests you or an employer. We are not talking about jobs here or impressions; we are talking about what's better and it's Assembly.

A dead OS? It's still alive, I use it. You want proof? I can give it.

You want the code? I can give it too. But, like I said, it's not my fault that I happened to use this OS to make the game. It gave a better "feel" of creation than newer OS and high-level torture.

This OS didn't even have all the necessary components for internet access... I have a newer one, yes, Windows 7 Pro, but this one is better for me because I get more efficient work done in my assembler and raw code, which I see performs better than 99% of all high-level codes.

[owl]

get more efficient work done in my assembler and raw code, which I see performs better than 99% of all high-level codes.

Nothing like an efficient "nibbles" (snake) clone! The one Microsoft made in Q-Basic 20+ years ago was so laggy.