Irrlicht Engine

in the speed irrlicht is very good i meant faster in developing!

I made my own system of checking for collision. The game map is made up of 800 25x25 pixel tiles, 32x25 of them (which will be bigger in the future) and your character is 25x25 pixels. Whenever you move, a while loop goes through an array (should I be using std::vector?) of 32x25 variables, and for every variable that == 1, check to see if your location is within a square of the array x * 25 and y * 25 and x * 25 + 50 and y * 25 + 50. If you are, it goes into a while loop to push you back, depending on which side of the tile you were on (so if you were walking in on the left, it subtracts only from your x axis).

I will add more things to put in the array's variables in the future. For example, 0 is fully passable by all, 1 is a block not passable by anything, 2-5 could be triangular shapes and 6 could be a thin wall or glass or whatever etc.

Works pretty well, but I thought of an easier and less CPU-demanding way of doing it. It just checks the tile you're about to walk on and if it's a block, go back though the character movement function but with your slope reversed. The only problem is it will be hard to walk right up against a wall, so I will probably do the while loop for the last part.

I know how I'll do map creation and loading, but I do have one question. Would it be best to load the map as a giant bitmap and the map file actually just tells the program where you can't walk or will the map file load and move the 800+ tiles every time your character moves?


How will I do shooting? I have an idea, but it's way complex. What I would like would be when you shoot, your bullet travels at a fair speed until it hits a wall or another player. I would like for it to be easy for me to add special effects later on, such as bouncing bullets.

Have an image for the bullet and then each frame move it a little bit further along its trajectory based on the time which has elapsed since the last frame. Then each frame you just test to see if it's collided with anything since its previous position and its current position. You could then add in things like bouncing by just altering its trajectory when it hits something and then it will just move on in the correct way in following frames according to its new trajectory.

Hope that makes some sense, let me know if you need any more explanation!

Well the problem is there's going to be many bullets flying around. I guess you could store each bullet's propeties in an array, but that could get complicated. I would have to make an array int bullet[100][3]. If you shot your first bullet, [0][0] would contain the x position, [0][1] the y, [0][2] the angle, [0][3] represents the type of bullet, ex. 0 = normal, 1 = bouncing 2 = rocket, etc. With that, there could only be 100 bullets at any time.

Okay maybe i don't know how to do map loading and creation! I thought I could save each tile type in a text file with something like 1,0,2,2,4,0,0,1 etc with each number representing the tile or using binary (hex would look like this)0100020204000001.

I need to either:

a) convert a char ex. "1" into int 1

or

b)be able to read from a file at a low level (is this called binary reading?) so that I could put the raw data of a byte from a file directly into an integer.

I can't seem to find a good way of doing any of these...

ha nvm I think I've got it...

the advantage of a 2d engine over irrlicht is rather simple.

all 2d classes in irrlicht are not made for 2d games and lacks the proper functionality.

irrlicht is fine for 2d except that you will be writting a lot of code to make advanced features work and by advanced I mean you'll probably have issues with images and all sorts of stuff since 2d is not a major focus of irrlicht devolopment at this time.

for those who don't know I'm basicly the resident irrlicht GUI expert under niko. I'm not bragging I just want to point out my background on this subject. probably not for long though there is a bit of a secret gui project underway for irrlicht atm.

i can say that 2d is almost unusable in Irrlichts for game development, except gui (sad but true) becouse of 2 reasons:
- it is not resolution-independent (3d is)
- stretching 2d images (i mean drawing 256*256 texture into 200*200 squeare on screen) always done WITHOUT any antialiasing, it is explicitly disabled for 2d operations (for unknown reason). But scaling billboards is a must have in 2d!

But tweaking the irrlicht code can fix both problems