Jump to content

  • Log In with Google      Sign In   
  • Create Account


Pointer2APointer

Member Since 15 Sep 2012
Offline Last Active Nov 05 2012 04:30 PM
-----

#4996303 High-level and Low-level languages.

Posted by Pointer2APointer on 01 November 2012 - 02:42 PM

Low-level is my bread and butter.

I've always loved knowing and wondering what was going on underneath all these symbolic English words on my text editors, IDE programs, etc, such as "include this", "load that", "call this", "return this".

Higher-level programming means simply writing instructions in a language that is not directly, or close to being directly, executable instructions from a processor for a specific instruction set architecture(C is not really "low-level" as Assembly languages are).

Lower-level programming is writing instructions that can more closely be executed directly by the processor(Assembly or machine code).

Assembly on a specific architecture is almost the lowest you can go without almost completely sacrificing readability. Binary code or machine code is the lowest-level execution done in general, but even that can get one step lower: microcode(although useless in almost every case for developers, and always pre-coded by hardware engineers basically).

It's almost impossible to do much of anything with machine code directly because it's extremely difficult to maintain, and you'd have to literally enable yourself to think along the lines of machine instructions for every miniscule instruction done by the processor.

Assembly is much more readable, but still very, very difficult for a newcomer to really grasp(I am still in the midst of learning Assembly for x64 after first mastering 8-bit Assembly from 6502 Assembly, which was used in Nintendo Entertainment System's console in 1985).

This is why higher-level languages get things done faster, because the abstraction from the processor is defeated using other tools and programs to "translate" the higher-level instructions into a directly executable format(on the machine code level, usually).

If you really want to go to low-level, it's a definite suggestion to start with lower bit-depth processors first(through a virtual machine or such).

Although low-level has lost its spark decades ago, it's still nothing more than amazing and useful information to know how it all works from the hardware itself.


#4991932 How much experience is enough experience?

Posted by Pointer2APointer on 19 October 2012 - 03:06 PM

The thing about programming is that there will always be trouble spots for every programmer, best or worst, top or bottom of the list.

If you haven't already made a "falling blocks" kind of game, which is like Tetris(without explicitly referring to it), you should proceed on there.

Platformer games give MUCH more experience that would be applicable to the kind of game you want to make, because they incorporate the more advanced work of professional games(such as artificial intelligence, gravity, field and space dynamics, etc.).

So my advice to you is ... not quite. Even though completing a Breakout clone is already good achievement, and pong as well, and the fact that you can do artwork makes it even better.

But if I were in your spot I'd progress through a few more projects before tackling a game that'll probably be harder than you think ultimately.

By the time you've completed games like Tetris and Super Mario Bros., you are ready to set the stage on any game you want(well, the first big stage of the stages).

I say this because those are classics; a side-scroller featuring many important aspects of advanced game development subjects, and an arcade-style game with falling blocks.

But you're definitely well on your way to accomplishing the "any game" feat.

Though it wouldn't hurt to practice a bit either, but you would do better to really (and I mean really) study and learn the difficulty involved in a complicated RPG game (and even the simplest RPGs are still complicated to some extent) before tackling an entire project on it to leave it in the dust, and have to start over anew from a lesser position of development success hierarchy.

I think I'll make a tutorial series on how to implement the mechanics of RPG games in code(although I'm not any programming expert, I have experience in programming and design).


#4990500 Making my first game

Posted by Pointer2APointer on 15 October 2012 - 02:17 PM

Making my first game


I have made pong, and now i want to make a simple game.


a tactical stratergy shooter, similar to xcom


It's a bit of an unreasonable stretch to attempt to make a game like XCOM, 2D or not, after making pong.

If you made pong, didn't you realize the difficulty of it just for such simple instances(two paddles, one ball, reversing velocity)?

There's no comparison from a simple pong game, even an advanced one, to a fully-fledged commercial-quality game series like XCOM.

I'd suggest you start smaller and work your way into larger, more complex scaled games.

Maybe you should migrate to a platformer-style game first: --> http://en.wikipedia.org/wiki/Platform_game

I will tell you though ... if you think a commercial-quality game is feasible, just try completing a simple platformer with a few levels(many good programmers have programming-plateaus here), and if you can do that you're well beyond a beginner.


#4989874 how to make isometric game

Posted by Pointer2APointer on 13 October 2012 - 01:57 PM

I suggest you start by overviewing the principles of isometric projection: http://en.wikipedia.org/wiki/Isometric_projection

Like anything in making a game, a game's development relies heavily on an idea, a computer programmer experienced with game programming, and/or a graphics artist(altough a programmer can be an artist, and vice-versa, etc.).

Regardless of the road you take, knowledge lends you the power to accomplish whatever task you wish anyway you want.

But basically, isometric game design relies on isometric projection principles in graphics, and computer programming.

You can check out some of the basics of computer programming here as well: --> http://python.about.com/od/throughacomputerseye/ss/begprogramming_all.htm


#4988851 I'd like to make a C++ game

Posted by Pointer2APointer on 10 October 2012 - 02:47 PM

When I code something in C++, it runs it in what looks like Command Prompt.


Because your build target is set to a console/terminal command-line window(in Windows this is DOS-style command-prompt).

It is text-based only - no images or graphics(unless they're made with character symbols or ASCII art).

There are a few options you have here, and quite some understanding that would help you out here.

Windows graphic-based applications on Windows OS run through software known as DirectX or DirectDraw for windowed graphics, and use the Windows API to manage the controls for the windows(GDI/GDI+ are used as well).

This stuff is a complete different implementation on command-prompt windows.

There are libraries that offer "wrapping" for this to avoid directly interfacing with this stuff for development if you find Windows API and DirectX to be hard(which many do find them to be).

As mentioned, SDL will "wrap" around the lower-level abstractions necessary for window management and graphics(such as DirectX and WinAPI). What this does is gives you an interface that will get you things done faster and easier than with Windows API/DirectX directly.

SFML will do the same, and so will many other libraries providing abstraction from the lower-levels of user-space software rendering of the operating system.

Aside from what the C++ disliker above is saying, SDL or Allegro is probably what you should be working on and studying now:

http://lazyfoo.net/S...rials/index.php

http://wiki.allegro....egro_5_Tutorial

All of the lower-level abstractions come with more programming experience. The Windows API is the lowest-level API that controls all window structuring and management on all Windows OSes so far, to note. It works alongside with DirectX for optimum software rendering. Learning them both can be ideal and useful, but at this point it would be a little farfetched.

I believe it has something to do with .txt files


Absolutely nothing to do with text files.


#4988492 __stdcall Class Constructor

Posted by Pointer2APointer on 09 October 2012 - 03:22 PM

_stdcall
pushes parameters backwards (right to left) on the stack.

_thiscall
gets pushed on the stack, but in normal order, and the
this
pointer is placed in the ECX register.

They are simply calling conventions for the compiler when generating object code during compilation.


#4987241 Game Engine from scratch using C++ and python - Where do I start?

Posted by Pointer2APointer on 05 October 2012 - 02:29 PM

I see that I've already been attacked for my poorly written game engine code tag. Posted Image

What I actually intended on getting at was that a member function within a class that draws and renders an image, and can return the position in a 2D plane/world can already be a simple game engine practice for beginners.

In fact, most games you'd write will have some form of an engine, or at least parts that can be transformed better to reusable code segments and sub-systems that handle game-specific data.

It was my mistake - you don't need to pass an argument to an image loading function containing the file name everytime it's invoked/called.

I was just aiming to simplify the idea, but I failed to elaborate more into the example, as I just wanted it to be simple. My bad.

If you really want better game engine examples, or from people who have more experience in game engine design (more than me at least), you can try a lot of the examples listed above, or for the sake of your topic's title, keep working on one yourself.

A game engine is a system that will act as a "wrapper" of some sort over a graphics library, like SDL, SFML, DirectX, OpenGL, and many others. It can dramatically change depending on the genre/target of the game.
For example, a platform game would contain codes that handle 2D Cartesian plane mapping, raster image formats in a window and coordinates (for 2D), sounds, AI for non-playable characters, positioning, objects/instances such as coins or items, an animation engine (to accurately load and animate images in memory), gravity and/or friction (if necessary), advanced collision detection systems help a bunch, and playable/game states and tile systems too(tile-based games often save more memory if programmed effectively).

As for 3D, well, it's a more difficult extension, as you have a third-dimensional axis awaiting you, along with several other aspects. Posted Image


#4986164 Game Engine from scratch using C++ and python - Where do I start?

Posted by Pointer2APointer on 02 October 2012 - 01:34 PM

First of all, you probably mean a VERY simple game engine, like maybe one that dictates coordinates on a cartesian plane of bounded raster images in memory in a window, and maybe input synchronization.

You can implement a super-simple engine like this, pretty much:

#include <SDL/SDL.h>
void ShowBMP(char *file, SDL_Surface *screen, int x, int y)
{
    SDL_Surface *image;
    SDL_Rect dest;
    /* Load the BMP file into a surface */
    image = SDL_LoadBMP(file);
    if ( image == NULL ) {
	    fprintf(stderr, "Couldn't load %s: %s\n", file, SDL_GetError());
	    return;
    }
    /* Blit onto the screen surface.
	   The surfaces should not be locked at this point.
	 */
    dest.x = x;
    dest.y = y;
    dest.w = image->w;
    dest.h = image->h;
    SDL_BlitSurface(image, NULL, screen, &dest);
    /* Update the changed portion of the screen */
    SDL_UpdateRects(screen, 1, &dest);
}

This is basically a skeleton source code that can be brushed up to draw images into memory.

It is reusable, and fixed now for any future readers.


#4985879 Hardware/Software Limits?!?!?

Posted by Pointer2APointer on 01 October 2012 - 03:44 PM

You can use one of the Wacom Graphics Tablet on Ubuntu(some versions are more buggy, or difficult than others to set up, but yeah).

And you can install Ubuntu on pretty much any machine, even cheap ones(but is that really what you want?).

And the above poster is quite incorrect. Linux machines may not be priority competitors in the market like Windows or Mac, but they can, for the most part, get you what needs to be done, done. You can run many printers, scanners, camera devices, etc. on Linux perfectly fine like on Windows and Mac(though the difficulty levels will be much higher in a variety of cases).

Also, Linux is free. Any decent, lower-end purchased computer system, with or without a pre-installed operating system and with a Linux distro like Ubuntu, can get you to do what you're requesting.

You also don't need a "modern machine" to run "modern software" exactly.

As for the memory management, Windows, Mac, and Linux-based OSes all do it differently. There is plenty of room for debate.


#4985874 As a beginner in Game Programming, I just realized something.

Posted by Pointer2APointer on 01 October 2012 - 03:27 PM

First and foremost, you can probably call me a computer philosopher.

I don't have much hands on experience with game programming like a lot of people here do, but I do study and practice computer science, hardware, and operating systems design, low-level programming, and the bridging between software and hardware through different platforms, kernels, and device infrastructure.

I will have to disagree with pretty much everyone here.

Setting up a GUI/UI for a game is in no way harder than creating an entire functioning game itself.

The time it takes to implement the ideas, structuring, and functions of these certain UI aspects of a game can take longer than the process of color-coding your way through a basic, tested, and experienced set of game code and logic that would otherwise take longer without the addition of pre-planning algorithms.

However, the elements of a game and its entirety are, at least to me, way more difficult, strategical, logical, and definitely much more overwhelming than a glossy, attractive interface would do on its own.

That is not to say that a UI is not important to a game at all, but I really doubt it's the hard part of the whole scenario when adding so many other elements to the process that are severely time-consuming.

Then again, easily, it's very arguable that any of us (anyone reading this post, or the OP) can challenge or debate on what defines a game's "user-interface" or "graphical user-interface" in the first place.


#4985856 Game creation software

Posted by Pointer2APointer on 01 October 2012 - 02:18 PM

If you're only experienced in Flash (e.g. no other programming languages, syntax, etc.) you shouldn't worry too much about APIs and libraries so fast.

First, learn Java 100%(okay, maybe not 100%, but learn it well). Practice on an IDE program called Eclipse: http://www.eclipse.org/

After you get more familiar with Java, look into Java Swing - it provides a graphical window with utilities, buttons, elements, etc:

http://docs.oracle.com/javase/tutorial/uiswing/start/index.html

After you get the hang of that pretty well, and after you get more Java-specific experience(try in just the OSes console window, terminal, etc. and practice with text-based windows for a while), then it's time to move to the more serious stuff.

Remember, you have to start smaller before you advance into more complicated tasks. Within months you can already be writing games easily.

A beginner to science doesn't just jump straight into string theory.


#4985137 Game creation software

Posted by Pointer2APointer on 29 September 2012 - 02:11 PM

The problem is that i want something more "complex"


Java is your starting haven for suitable web applet game creation: --> http://en.wikipedia.org/wiki/Java_(programming_language)

Java applets can be directly integrated on web pages, and it's more powerful and complex than Flash.

Also, I checked out that game you want to make ... keep in mind that it's not an "easy" task to accomplish a game like that.

In reality, many programmers will struggle to get ping pong game logic and flow to be accurate, because even the most simple games require time and strategy.

The game you want to make is a bit farfetched from just being a Flash programmer. You should start smaller, and work your way up.

My advice: learn Java, use its API (or any graphics API/library it can bind with) and practice executable programs first, and try to accomplish more easier games (like some with direct raster graphics in memory, not 3-D models, complex animations, AI, etc.).

You are setting yourself up for a big goal before completing several smaller ones.


#4984081 Hi, I'm new and need some advices

Posted by Pointer2APointer on 26 September 2012 - 01:41 PM

When I was at your stage, the thing that eased me into, let's say, "real programming" from scratch, was GameMaker:

http://www.yoyogames...amemaker/studio

Believe it or not, there was one point where I knew absolutely nothing - not a clue on how computers worked from square one.

Programming is writing instructions that perform actions, in the simplest sense.

GameMaker can be witnessed as real programming - it just helps you get the job done way easier than without most of the tasks done for you.

One day I just decided to find out what programming really is, how computers really work ... and I did.

My first ever language learned was, believe it or not, as a total beginner (excluding some GML), C++, bare bones. Yes.

It was so complicated at first, but after months passed, it was like a newly spoken language.

You can start programming from any level or step, so long as it's not so advanced you'd be lost as to where to start observing.

For example, a typical computer-user with absolutely no programming skills or knowledge would be hopeless trying to analyze an Assembly language(low-level programming language).

But a beginner can start with C, C++, Java, etc. It depends on which one suits you best.

But here are some things you need to know, and that will make everything so much easier for you, from my experience:

1.You have to know how a programming language works, the basics of how computer hardware works, and know what and how you can do certain things in that language before pursuing game programming.

I'm not trying to shun anyone from programming here, but knowing proper language syntax, rules, data types like arrays, vectors, characters, linked lists, pointers, etc., are all a major bonus in programming, and the best part is - they are also a bonus in game programming specifics as well.

2.You need to know the mechanics of games.

A game-loop is a function/method or region of code in your program that constantly loops and executes your game, game logic, game functions, animation, artificial intelligence, input and output, graphics, etc. Anything you want, but without a loop it would be nothing.

What I'm trying to say is that in order to accomplish making a game, you are really going to be urged to know how games work, and the best practices on how to get certain tasks done. To make a game you will need something to provide a graphical window (mostly graphic - though games can be made through text-only interfaces), and there are things called libraries that do that for you.
Some languages (like Java) come with that stuff, and others (like C++) do not by default. You need to set up these libraries and link them with your program code, bind them together, and the result is executed through the windowed interface.

The more you know about games, how objects in games work, and how you can implement the methods of how to code these things, the faster, better, and more smarter programmer you'll be.

Mario in Mario Bros. moves left and right on a 2-D dimensional axis(same as Luigi and all the other characters).
You implement x-coordinate axis positioning on a screen, and update the window repeatedly in your game-loop code to keep Mario's position "repainting" itself on the screen. As easy as following those basic levels of logic you're already on a good track.

3.Learn to observe more, analyze details more, and use the tools you have, or make your own, to accomplish in-game statistics.

You should never let a good old array go to waste. Learning data types are essential, but knowing how to use them in all the right places is what puts the icing on the cake. Think about the things you want your game to do, and know how you can transition those ideas into a real working executable program on your display. If I want Mario to simply move left and right, I'd learn what left and right means - and then I'd learn how to implement an x (or left and right) axis to increment or decrement values necessary to adjust an image's position on the screen, and take all the necessary steps to get it right how I want it.

I can't stress this enough - learn the basics, learn how things work, and then do them as best you can.

-> http://en.wikipedia....ame_programming


#4983748 Intro and a few questions

Posted by Pointer2APointer on 25 September 2012 - 03:19 PM

Everyone has their own programming language (s) of preference.

I agree with ATC on the curly-brace family languages, like C, C++, Java, etc. I, too, would turn away from programming if I would've started with Pascal(not that Pascal is bad, it's just that the syntax is not to my likeness).

Objective-C, Smalltalk, Visual Basic, etc. I also find those to be other dreaded syntax languages to me.

By combining programming language knowledge with graphics development, you'll be two steps ahead of many people in the computer-related fields.

Honestly, even basic knowledge of a language like C++ can open many doors for you with innovation and game development, and some people find that once they start learning and getting the hang of a language, they just keep going ... good luck.


#4983743 No knowledge of programming, wish to create an android game without aforement...

Posted by Pointer2APointer on 25 September 2012 - 03:04 PM

Edited my last post.

Sorry for stating that I "knew" there was no way to develop for the Android OS without coding knowledge.

Truth is, now that I think about it, you can do so many things nowadays that you couldn't 10-20 years ago in software development and production.

GameMaker puts ease on the souls of those less eager to be more of a hardcore programmer using C++ and graphics libraries, etc.

They are all software, and many easy-to-use programs can give direct executables from drag-and-drop interfaces, but, to me at least, it's not really programming a game if you use a drag-and-drop interface and millions of drop down options all presented, modified, and designed for you.

Programming should be telling what needs to be done, not being told what's available to me to make something out of with your otherwise inclusive arrangements and limitations.

However, the gift of things is that even if you don't want to learn programming, you can still "program your own executable software".

No offense, but it is true that programming from the ground up without tools, pre-defined interfaces, window and memory management, loadable/insertable modules, sounds, effects, and rendering 3-D models, is not for everyone.




PARTNERS