Quite Basic Stuff - load image to screen and manipulate, how? v nooby and messy, sorry

[ChrDybdal]

(if someone is able to rephrase this to something more simple and understandable, plz plz plz be my guest ;p)

Hi everyone

Basically I just wanna try making some sort of a 2d platformer cuz I like mario games and stuff.. ;p

Info on me:

I'm fairly new at programming, have been watching several tutorials and reading a bunch of stuff from random places
(long basic tuts, examples of ppl coding random stuff, NES assembly stuff, c++ stuff, java stuff, xml stuff, python stuff, lua stuff, blender stuff, jmonkey stuff, and probably some other stuff -- c++ being the most extensive, rest mostly being 'hey wats this? / let's play around with this for a few hours' level study)


Pre-question stuff:

With starting point for this question being somewhere around 8-bit NES lulz..:

NES stuff seems fairly simple in regards to getting an image put on the screen and then manipulating the position and colors of the image
- fill some memory with code, get that code sent to the gpu on vblank-stuff.. simple palette lulz and fairly simple altering of the position of the image..

In C++ for a PC today I understand that far more resources are available

The Actual Question:


- How would I go about loading fx. a .jpg file to the screen, moving it, changing speeds it moves at, and how would one typically trigger an event based on position of the picture - or the overlapping/collision of 2 pictures?
(oh yea and capturing keypresses ..)


My ideas on how a solve would like like.. sorta..:

My own 'vision' as to how the collision would work would be something like
'if a pixel of picture1 has the destination of a pixel in picture2, then deny picture move and trigger event'

Loading a pic to screen I'm far more 'wat the hell' about..
- I imagine using top left pixel of picture (assuming rectangle-style) and puttin that pixel on topleft part of screen and the rest of the pixels in the picture's topmost line on the following x-coordinates, then the next y position fill's it's x-coords and keep going until the pic is loaded..


From 8bit lulz to modern day lulz the resolution difference is my imagined biggest hurdle, but also it seems that more than just messing with simple assembly stuff I need to have a vast insight into libraries of different sorts
- If anyone can help me with some sort of 'plan' for how to study libraries as to get a good 'tool-belt' to use for whatever that would be awesome-- finding random libraries and just looking at their code and comments is .. well, seems like there's a LOT of libs out there, many of which are probably superfluous.. so.. any help here would be making my day..




Hope this was enough to make it understandable what I would like help with, and that it wasn't too much to make you go 'this dude needs a trout-slap' .. :)

  *.* // ;p 

Pre-Thanks to any and all help and commentary

[Disch]

I was going to skip by this topic without responding because of your use of "plz" and "lulz"... but then I saw you talking about the NES and got all excited. I was an NES emu dev a while back so for some reason any express of interest in it is a way to endear yourself to me. I'm weird like that.

Anyway let me start by saying that modern graphics have come a long way since NES era. Whereas the NES had a single static playfirled/background and a handful of overlaying sprites... modern graphics don't have any of that. Instead everything is based on rendering polygons. A graphical scene can consist of any number of polygons.

Rendering polygons is not necessarily any more difficult than doing what the NES does (in fact... in some ways it's simpler). It's just different. So any experience with NES graphics will not really help much.

How would I go about loading fx. a .jpg file to the screen

First of all, you typically wouldn't use a jpg because jpgs are lossy and would look like crap. You'd use a png.

Secondly, you would render a "textured quad". A quad is just 2 triangles placed next to each other to form a rectangle. Each point on the rectangle has a position (where you want it on the screen) and "texture coordinates" (where you want to pull the texture/pixel image data from).

Many graphic libs use the term "Sprite" instead of "Quad", but it basically means the same thing.

moving it,

As mentioned, each quad has a position. So all you have to do is change its position and redraw the screen.

changing speeds it moves at,

This has nothing to do with actual graphics, but is rather a logic problem.

Typically the game world is updated several times per second. For a beginner, it's usually easiest to have the update rate the same as the screen refresh rate. So if you want your game to run at 60fps you'd do something like this:

while( game_is_running )  // the main game loop
{
    get_input_from_user();
    update_logic();
    redraw_the_screen();
}

Every logic update you'd move all your in-game objects at a certain rate (example: 2 pixels per update). To change the speed, you simply adjust that rate (1 pixel per update would move it slower, 3 would move it faster).

how would one typically trigger an event based on position of the picture

You wouldn't do it based on the picture, you'd do it based on the object. You have to separate "pictures" from "objects". One is graphical and one is logical.

You'd have a logical object which has a position. That object would also own a sprite/quad which it would draw at its current position when the object is drawn. If you move the object, it would also move the picture.

Then in your game logic updates... you can check in-game objects to see if they overlap. And if they do, you can run whatever code to handle that.

This is commonly referred to as "collision detection" and can get pretty complex depending on the type of collision you want. But simple 2D "bounding box" collision is not hard... you just check to see if two rectangles overlap each other.

(oh yea and capturing keypresses ..)

Any lib that you'd use for this has a way to capture input from keyboard/mouse/gamepads. You often have 2 options:

1) you can poll the realtime state (ie: is a key being held down right at this moment?)
or
2) you can process buffered messages (ie: your game gets sent an "event" or a "message" when a key is pressed and another when a key is released. You can watch those events to keep track of when keys are being pressed).

For games, #1 is usually easier.






So all of that is fine and dandy... but it doesn't answer the real question of how you can write a program that does all of this. The answer to that is use a library.

I frequently recommend SFML because it's very easy to use and very fast.

http://sfml-dev.org/

Download that, get it set up, and start running through its tutorials. If you have questions you can post them here, as myself and a few others on the boards are pretty familiar with the lib.

[ChrDybdal]

"but then I saw you talking about the NES and got all excited."

aye, with NES comes fluffyness, like lulz .. it's hard to shake (damn mario clouds..) :)

thnx for response =)