• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
xdc

low level programming

8 posts in this topic

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. [i]For years, I’ve had misgivings about people learning programming[/i] on [b]Win32[/b] ([b]unix[/b] / X would be even worse), where it takes a lot of [b]arcane crap[/b] 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
0

Share this post


Link to post
Share on other sites
[quote name='hit' timestamp='1348291358' post='4982579']

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
[/quote]

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

Share this post


Link to post
Share on other sites
You could get your hands on a [url="http://en.wikipedia.org/wiki/Raspberry_Pi"]Raspberry Pi[/url], 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. :)
0

Share this post


Link to post
Share on other sites
A modern day equivalent of that type of thing in C++ might be something like [url="http://code.google.com/p/pixeltoaster/"]Pixel Toaster[/url] - 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 [url="http://sfml-dev.org/"]SFML[/url] 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 "[i]copy and pasted code that they probably don't understand[/i]" is already taken care of and hidden, so you can just go make games. Edited by Servant of the Lord
0

Share this post


Link to post
Share on other sites
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 [i]actually [/i]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 [i]reason[/i] for it: we can do [i]much [/i]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 [i]not[/i] be a waste of time. What you need to do is get EVERYTHING (and I mean [i]everything[/i]) 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 [i]is[/i] 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: [url="http://wiki.osdev.org/Main_Page"]OS Dev[/url]. 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...

[b]EDIT: [/b]

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 [url="http://www.brokenthorn.com/Resources/OSDevIndex.html"]here[/url]. Edited by ATC
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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 [url="http://www.armadilloaerospace.com/n.x/johnc/recent%20updates/archive?news_id=295"]came from this post[/url].

The two paragraphs before it give plenty of context and change the meaning of "low level" and "arcane crap" considerably:
[quote]
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.
[/quote]
After that is the OP's out-of-context paragraph.
[quote]
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.
[/quote]
Then it continues:
[quote]
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.
[/quote]

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0