For the past few days I have been learning assembly and I was wondering how to display graphics on the screen.
I'm doing this just for fun because I feel like I'm starting to burn out on my main game project and I thought I would do something fun like learn assembly. However displaying text on a console wasn't very exciting for me. So I'm taking it to the next level.
So, does anyone know how to start game development with assembly?
Why do you want to do this? What do you hope to gain? Yes, there is still the ability to write optimized assembly, but you can write just as optimized code and write it far quicker in a higher level language with today's compilers. I certainly recommend learning assembly, but for no other reason than to know what is going on behind the scenes. It's a step up from writing code directly in binary. It's like learning how to fix an engine to get your driver's license.
Lessie if I can explain better: (or maybe just make it more confusing)
const int* type1; // non-const pointer to const int
int* const type2; // const pointer to non-const int
int value1 = 1 * 2; // 2
int value2 = 2 * 1; // also 2
typedef int* IntPtr;
const IntPtr type3; // const pointer to non-const int
IntPtr const type4; // ALSO const pointer to non-const int
const int onePlusOne = 1 + 1;
int value3 = onePlusOne * 2; // 4
int value4 = 2 * onePlusOne; // 4
#define INT_PTR int*
const INT_PTR type5; // non-const pointer to const int!
INT_PTR const type6; // const pointer to non-const int
// of course if the * isn't there, suddenly const is commutative
const int type7; // const int
int const type8; // ALSO a const int
I'm still lost. Maybe I'm reading your example as compilable code and it's not? type1 - 8 are not used with value1 - 4, so I'm lost on the math issue. How does const int vs. int const change the way the compiler calculates the mathematical expressions?
Its kind of funny how those two modes work, they have basically an entire complete PNG or JPEG file where the pixel data should be. (you can read in a JPEG file, stick it inside of a bitmap container in memory, and send it to GDI and it will render it)
Not really. It's a useful metric- at least it would be if they implemented it properly. Gives you a ball park figure of how complex a project is.
It really isn't. Brackets, for instance, are arbitrary. They make the code cleaner, but do not translate to machine code. There is quite a bit in all modern languages that exists for aesthetics and code organization that do not have any effect on the final machine code.
is equal to this:
Your code really isn't any more compact in the first case.
I've been wanting to make a text adventure game for years. I've been programming for 30 years. Text adventures are easy to write, so long as you don't include a command parser. This is absurdly hard to get right. I've tried and failed. Parsing the individual commands is easy. Applying the parsed commands to grammar rules is not so. If you can find a program that does this for you, use it!
This was a common theme back in the 90's when graphics APIs either didn't exist or were in their infancy. I have several very old computer graphics books that detail how to make something useful, from start to finish, and all use software renderers. I think the focus has shifted now to explaining how to use the various features of the different APIs, and since the APIs are so complex, the authors really do not have the time or space for much else. It is left to the reader to assemble the pieces into something useful.
That being said, I no longer recommend buying books on any computer graphics related subjects. The technology changes so fast these days that by the time the book makes it to print, it is seriously outdated. You'll find more up to date stuff online where changes can be published immediately.