Jump to content

  • Log In with Google      Sign In   
  • Create Account


caldiar

Member Since 06 Feb 2005
Offline Last Active Dec 13 2013 07:47 PM
-----

#4982488 Representing player classes in c++

Posted by caldiar on 21 September 2012 - 02:33 PM

I just saw a similar thread with people debating how detailed an inheritance tree should be and when you should choose composition instead of inheritance; from that thread I'd say there's no 'best' way to represent your player.

Rather, write out a description of what your player character is and what it has.

In the simplest form, a player is a creature that has an inventory and can be controlled by a person.
A monster is a creature that could have an inventory and is controlled by the computer.

The main difference between a player and a monster is that the player is controlled by a person. You could make a generic creature class with health, mana, stats like strength, and have it hold an 'inventory object' which is represented by an inventory class. Then you would attach the input from a person to the generic creature's movement methods and that becomes your player. Everything else that isn't hooked up to an input device (and is controlled by the computer instead) is your monster.

Hopefully that helps out some.


#4974888 DirectX or SFML or SDL? c++

Posted by caldiar on 30 August 2012 - 01:25 PM

As a result, it is also faster than SDL because of hardware acceleration.


SDL also supports hardware acceleration but it's just not enabled by default. When you compare SDL's software rendering to SFML's hardware-accelerated renderinig SFML is going to blow SDL out of the water. You should find they're pretty close to each other when both are in hardware-accelerated mode.

It seems like the general consensus is to go with SFML so I'll back that. I've just had no experience on it so couldn't give an opinion on it one way or another.


#4974558 DirectX or SFML or SDL? c++

Posted by caldiar on 29 August 2012 - 02:25 PM

Indeed, it has software rendering abilities. However, as the OP mentioned an intention to transition from 2D to 3D at a later point of time it seemed safe to assume that OpenGL (if either of the libraries were chosen) would be used at that point.

With that in mind, I'm pointing out that SDL and SFML are going to be dishing up their more powerful graphical goodness through exposure to OpenGL, rather than DirectX. This isn't to say that you can't use DirectX with either of them, it's just that the libraries, as you said, have a wrapper specifically for interacting with OpenGL.

The tutorial site only mentions OpenGL near the end probably because it's not something most people need to know immediately when jumping feet first into learning SDL. I don't know though since I didn't write the tutorials on that site.


#4974549 Cursor obliterating the background.

Posted by caldiar on 29 August 2012 - 02:12 PM

oh man I should have totally picked up on the lack of a buffer clear. That very same issue happened with me years ago when I first tried writing a side-scrolling 2D shooter and had trails of characters being stretched all over the place.

The floating point number exists as an assumption. I assumed the mouse coordinates were floats. Since you're just working with ints there then you should be golden.

Glad to see you got this sorted out.


#4974545 DirectX or SFML or SDL? c++

Posted by caldiar on 29 August 2012 - 02:05 PM

DirectX is a lower-level API for interacting with the graphics device.

SFML and SDL are higher-level graphics libraries which simplify a lot of tedious work involved in using a lower-level API like DirectX or OpenGL directly.

SFML and SDL both sit on top of OpenGL. I don't have any experience with SFML but it, as well as SDL, have the ability to let you directly write OpenGL code if you'd like to dig into some more advanced stuff that neither library provides a simplified method of doing.

I believe neither SFML nor SDL are better than one another. It's just a preference - like OpenGL vs DirectX (ignoring cross-platform arguments and special use-cases).

I'd personally recommend using SDL. I know for a fact there's plenty of great tutorials on getting started with it and it's fantastic for 2D games. Later on you can jump into 3D graphics programming by using the OpenGL bindings with SDL.

Check out http://lazyfoo.net/S...rials/index.php for some quick, easy, well-written tutorials on setting up and using various parts of SDL.

SFML seems to be under active development though and has some interesting features to it.

Grab one, run with it, follow the intro tutorials and play around.


#4972714 Game Engine Programming

Posted by caldiar on 23 August 2012 - 01:41 PM

I might have missed this but, why do you want to make a game engine? What is your goal? Is this purely for education to help you learn programming as it's related to videogame development or is this to build an engine to use for a game you want to make?

There are plenty of existing solutions out there for game engines. If this is an educational experience I would say you would be better served downloading the source code to an existing game engine (idtech4's source was released recently) and modifying a piece at a time. You will see more immediate results and get a look at how things are typically done (with the idtech4 suggestion this applys to the way id software writes FPS games).

Writing an engine first with the intention of using it to build a game will only limit what you can do in the game later on. Perhaps you didn't forsee a certain condition in your game that your engine wasn't designed to handle. Changing that could mean a major refactor. Alternatively, if you focused on just building a game first, an engine will naturally develop as a consequence of developing games repeatedly and identifying chunks of code that you use over and over again which you can set aside and bundle into what would be your engine (a big hunk of reusable code).

Also be careful when trying to become familiar with a ton of different areas of programming at once. Don't mistake the notion of being familiar with a concept and actually truely knowing a concept. When I was first starting out I would focus on a ton of different concepts only to declare that I "know" an area of programming and can move on to the next. This was not the case. I had a shaky understanding of what is kind of going on. What I'm trying to say here is that you should pick an area that's interesting to you first to focus on. Put your time and energy into one area whether it be physics simulations, artificial intelligence, shader programming, particle systems, whatever. Keep building your programs around that specific subject and keep working on that until you truely know it. Simply glossing over the details will only be doing wrong by yourself. Don't cheat yourself out of properly learning the ideas.


#4972019 Lighting in caves

Posted by caldiar on 21 August 2012 - 06:19 PM

The first thought that comes to mind to define a cave system is to cast rays from the edges of the blocks in the area in question towards (and away from) the sun. You'll end up with an odd shaped cone volume of sorts defining the area in the cave that's visible to the light source.

This can be used to define which blocks receive light and can be used to define the cave volume by saying "the volume that is not in the lit cone volume and below the ray cast point".

Possibly a brutish approach to it. I'm not really familiar with the current techniques used today.




PARTNERS