8 replies to this topic

[hit]

I've learned C most of C++, some algorithms/Data structures, etc started learning win32 console systems programming, but been discouraged as i wont be able to look at the inner workings like I could with linux. I want to stick to a lower level, so im avoiding api wrappers like MFC, qt, etc

quote from john.c

"In fact, I think it would be an interesting environment for beginning programmers to learn on. I started programming on an Apple II a long time ago, when you could just do an “hgr” and start drawing to the screen, which was rewarding. For years, I’ve had misgivings about people learning programming on Win32 (unix / X would be even worse), where it takes a lot of arcane crap just to get to the point of drawing something on the screen and responding to input. I assume most beginners wind up with a lot of block copied code that they don’t really understand."

I want to evenutally learn both win32, and linux.
Should I learn something else before diving in? Would learning assembly first help?
should i just say fuq it and continue with win32?

any help appreciated

[Hodgman]

If you want to "just start drawing to the screen", like you could back in the days before modern OS's, you can look up "Mode 13h"... however, to use it these days, you're still going to learn how to use a bunch of arcane crap just to figure out how to write/run these kinds of programs. You'll probably need to use an emulator like DOSBox.

If you want to be able to draw stuff ASAP, but don't want to learn an OS-specific API like Win32, you could try an alternative multimedia API such as SDL or SFML -- these are also quite popular for simple game programming.

Or if you want to continue with basic console programming, but with more graphical options, you could try ncurses.

Edited by Hodgman, 21 September 2012 - 11:57 PM.

[wqking]

I want to evenutally learn both win32, and linux.
Should I learn something else before diving in? Would learning assembly first help?
should i just say fuq it and continue with win32?

any help appreciated

Win32 is a platform, it has nothing related to low or high level programming.
Even if you learn assembly, your assembly code can still control Win32 API (unless you want to go back to DOS 16 bit assembly, but you shouldn't).

So you can still keep yourself on Win32 and learn something really helpful.
I suggest you continue on your C++ and data structure and algorithm. That will give you quite deep inside into how computer works.

About assembly, from my very personal experience, you may learn a little bit but it won't give you as much as value as C++ or algorithm knowledge (no offending to assembly fans). I was a big assembly fan 10 years ago, I even implemented OOP in assembly and tried to understand X86 protected mode. But most likely I won't have a chance to design operation system or design a new method for OOP, my those knowledge doesn't help me in nowadays.

Also, what's low level programming? When I started programming many years ago, I thought assembly, protected mode, or anything that can control the CPU port or video memory directly is low level and really cool. But now I don't think that kind of "low level" stuff is helpful. On the contrary, the "high level" stuff, such as design pattern, algorithm, data structure, is much much helpful to your programming life.

However, my above opinion is all about general programming. If you are going to optimize for a 3D rendering engine, you may have to learn assembly and how video card works, etc.

Just my 2 cents and my personal experience.

[Goran Milovanovic]

You could get your hands on a Raspberry Pi, and try programming that (I plan to do this soon). Or, if you really want to get "down and dirty", get an FPGA board, and make your own hardware architecture ... Ok, that may be a little too much, but I would actually like to do that ... eventually.

[Servant of the Lord]

A modern day equivalent of that type of thing in C++ might be something like Pixel Toaster - it just gives you a window and lets you put and get pixels, so you have to write all the details of how to load images and blit images yourself. This is actually contrary to what Carmack was saying, though.

However, I'd recommend SFML or SDL. Either one will easily handle window creation, user input, and loading and drawing images, letting you get straight to making games without the boiler plate code he was talking about, that's required for Win32. It's not lower level you want to go, it's higher level where the "copy and pasted code that they probably don't understand" is already taken care of and hidden, so you can just go make games.

Edited by Servant of the Lord, 23 September 2012 - 10:18 PM.

[ATC]

I really disagree with the quote from John C... Some people are a bit too nostalgic about the "old days" of computing, and some people have even failed to keep up with the times and learn new things. That quote sounds just like some hardcore nostalgia and unwillingness to let go of the past and embrace the future. Does Modern Warfare II run on an Apple II? No... So the "old ways" of Apple II programming are not really relevant in today's world (unless it's for learning or studying computer history). All of this "arcane crap" being talked about is actually the code initializing modern rendering APIs and setting up a system to run an application. This is how modern computer systems work, and there's a reason for it: we can do much more with our systems now because all of these ingenious frameworks, APIs and sub-systems have been designed for us to write our userland applications.

However, that being said, it's clear you want to learn about deep, low-level programming; and that is not a bad thing. I was once on the same learning path you are on now. And speaking from experience it definitely will not be a waste of time. What you need to do is get EVERYTHING (and I mean everything) out of the way between you and the "metal" (your hardware). And the only way to do that is to write an operating system or a sort of "operating application" of your own.

Before you commit suicide from the horror of having to write an operating system: don't! Please put the gun down! Lol.. I'm not talking about writing a new Windows or Linux. I'm talking about writing a very simple hobbyist system. Plenty of people, including me, have done it. It is extremely difficult. I would venture to say it is undeniably the most monumentally complex and difficult areas of software engineering in existence. But flirting with it and getting your system working will give you unparalleled insight into how modern computers work.

Basically, you want to start of writing a simple bootloader that just prints some characters on the screen. Then advance further and make it more complicated. Then move on to a bootloader which loads another module that is written in C and kicks the processor into 32-bit protected memory mode. When you get to this point you can truly call your work a miniature "operating system"; though a very simple one. From there you can learn to do anything; even hardware accelerated graphics and visually appealing GUIs. You could even learn to put the CPU in 64-bit "long mode" and write an x64-based system/app. You can write your own input drivers for keyboard, mouse, etc. You can implement audio as well... There's really no limit other than your time and dedication. But by the time you get sick of it you will be a computer "jedi" of sorts, and no programming task will ever again seem too far out of reach (from a difficulty/complexity standpoint).

The best place to get started is the place that got me started: OS Dev. They also have forums with a lot of experienced and knowledgeable people. Just be sure you read through the Wikis and forum rules before posting, as it's a bit annoying when people ask questions already found in the FAQ and Wiki lol...

EDIT:

It's also helpful to download a decent virtual machine. Microsoft and Sun both offer pretty good ones. There are two reasons for this: 1) no risk of corrupting/damaging a real, valuable PC 2) no need to reboot systems, struggle with DVDs, flash drives or floppies and you can go straight from build >> testing in an instant.

You might be thinking you cannot use Visual Studio to write an operating system... and you'd be wrong. My OS was entirely written in Visual Studio using C and C++ (as well as x86 assembly language). My kernel was also a PE module (.exe). All you need to do is write a bootloader that can read PE headers. It's a bit tricky but the reward is worth the work. I also automated builds and set things up to where all I had to do was click "Build Solution" and reboot Virtual Box (my virtual machine) to run and test my system. However, I never got around to setting up a debugging environment for it. That's a very complex subject. BTW, I used the GRUB bootloader for my system.

You can find an excellent, comprehensive guide to developing an operating system in Visual Studio here.

Edited by ATC, 24 September 2012 - 03:49 PM.

[FLeBlanc]

Hell, I remember having to do a lot of arcane crap even back in the EGA days. Sure, the DOS interrupts would technically allow you to push a pixel with brain-dead ease, but if you wanted to push pixels with the kind of speed you needed, you had to write some clever assembly rather than using interrupts. Computers are arcane, no more or less so than they always have been. There really aren't many analogues to computer programming in human evolutionary history, so nobody really comes into it well suited to handle the complexity. The only way you become good at it is by diving into the complexity and training your brain to grok it. Whether that's through deciphering Win32 internals or through writing MASM assembly or Python or C++ is, in the end, largely irrelevant. IMO.

[Pointer2APointer]

I don't know where you get the idea of the Windows API being "low-level", really.

What do you mean "low-level"? Like, maybe Assembly?

You don't need to know any Assembly to code in Windows API. Windows API is the lowest-level of user abstraction between the Windows shell GUI and the user, but it's definitely not "low-level" in terms of abstraction between the processor's machine code, the instruction set architecture, or the like.

Real "low-level" equivalent stuff would be killing the offering of semantics, symbolic mnemonics, and classification through syntax and structure of a higher-level language converted to an executable machine opcode, binary format, or whatever the goal, usually being executable programs in memory.

If you want Windows API, go ahead - it's not really "low-level" though.

And what does Linux have to do with wanting to program in "low-level" anyways?

If you want to "just draw to the screen" in a "low-level" way, go into OS development, use VGA, and test it on a virtual machine - but that won't be pretty.

Edited by Pointer2APointer, 25 September 2012 - 04:06 PM.

[frob]

Sorry for coming late to the party, I was on vacation for a week.

ALWAYS consider the context for a quote like that.

The blurb John Carmack blurb he was quoting came from this post.

The two paragraphs before it give plenty of context and change the meaning of "low level" and "arcane crap" considerably:

I am a big proponent of temporarily changing programming scope every once in a while to reset some assumptions and habits. ... This time, I decided I was going to work on a cell phone game.

I wrote a couple java programs several years ago, and I was left with a generally favorable impression of the language. I dug out my old “java in a nutshell” and started browsing around on the web for information on programming for cell phones. After working my way through the alphabet soup of J2ME, CLDC, and MIDP, I’ve found that writing for the platform is pretty easy.

After that is the OP's out-of-context paragraph.

In fact, I think it would be an interesting environment for beginning programmers to learn on. I started programming on an Apple II a long time ago, when you could just do an “hgr” and start drawing to the screen, which was rewarding. For years, I’ve had misgivings about people learning programming on Win32 (unix / X would be even worse), where it takes a lot of arcane crap just to get to the point of drawing something on the screen and responding to input. I assume most beginners wind up with a lot of block copied code that they don’t really understand.

Then it continues:

All the documentation and tools needed are free off the web, and there is an inherent neatness to being able to put the program on your phone and walk away from the computer. ...

I spent a while thinking about what would actually make a good game for the platform, which is a very different design space than PCs or consoles. The program and data sizes are tiny, under 200k for java jar files. A single texture is larger than that in our mainstream games. The data sizes to screen ratios are also far out of the range we are used to. A 128x128x16+ bit color screen can display some very nice graphics, but you could only store a half dozen uncompressed screens in your entire size budget. Contrast with PCs, which may be up to a few megabytes of display data, but the total game data may be five hundred times that.

The article then goes on about how he switches between PC development at day --- games requiring gigabytes of memory and multi-GHZ processors --- and then switched over to Java at night for 2" screens and <2MB total memory running on 60MHz processors.

Considering his entire quote in context, the gripe is not that you must learn "arcane crap", but that beginners generally don't understand it, and are generally far beyond their understanding to do something simple.

In the context of his article, writing simple J2ME apps for mobile is much faster an easier than writing a D3D PC game. It is much easier for a beginner to understand all the steps involved, where a beginner on D3D struggles to understand the COM interfaces and window management and generally ends up copy/pasting without understanding the necessary just to create a plain black, empty scene.


When I wrote my first game in '83 I did it in about 200 lines of code. It was trivial to display graphic sprites on the screen and to get input. Compare this to a modern PC game where 200 lines of code won't even handle the simple window management. In that respect, I completely agree with his article.