ALLEGRO BITMAP vs SDL_Texture
Battyhal

Hi everybody !.

I´m reading a book about game development using SDL 2.0. And i have had the crazy idea of implement the code from that book using ALLEGRO 5.x instead. Hopefully i will learn something (or a lot) of OOP and of course ALLEGRO (i know sounds stupid to read a book about SDL to learn ALLEGRO ;)) ;D.
In the chapter about handling graphics and drawing the author talks about loading an image from a file (BMP for example) and from that image create a texture to be drawn in some rectangles made for that purpose. But i have not found something similar about loading textures and drawing them in rectangles to get an image working neither in the ALLEGRO Wiki nor in the manual. In ALLEGRO is not necessary to do that, am i correct ?, or am i missing something about loading a texture from a file and from that texture create a bitmap in ALLEGRO ?.
I have read the examples in the Wiki and is far more easier just loading an image in an ALLEGRO BITMAP and voilá!.

As usual i really appreciate your time !. :).

Elias

Yes, ALLEGRO_BITMAP by default will use a texture (sometimes called a "video bitmap" in the documentation). You can use al_set_new_bitmap_flags to change that if you need to.

Battyhal said:

Hopefully i will learn something (or a lot) of OOP

Make sure to pay attention to when not to use it. There is only a small set of problems where OOP is the best solution, for everything else there is better things.

Battyhal

Thanks Elias!. I´m glad to have chosen ALLEGRO if is so complicated just to load a BMP image in SDL. ;).

Elias said:

Make sure to pay attention to when not to use it. There is only a small set of problems where OOP is the best solution, for everything else there is better things.

Really ?? :o. This is my first approximation to programming and i had read OOP was the best (or one of the best) way to make a program more readable and understandable because is similar to human thinking and because is an evolution of structured programming and modular programming. Should i start learning another way?. And why is not always the best solution?, which are the other ways?. Too many questions right? ;) .

Thanks again!. :).

Edgar Reynaldo

There's nothing wrong with using OOP to organize your code. It's modular, and it makes sense. However, you can sometimes code faster procedurally. That's not to say it's better or worse, but it has its drawbacks too. It tends to get messier faster, at least in my opinion.

Chris Katko

I would not have mentioned OOP's drawbacks at all.

It has SOME drawbacks.

Game programming, and programming in general, is about managing complexity. OOP is an "almost" perfect tool to do that. Use OOP to help make code make sense.

99.99999% of all indie games are going to be limited by your ability to cope with complexity, and not performance. And when there are performance problems, 99% of those are due to using the wrong algorithm (e.g. n^2 / searching within a search, instead of a more appropriate setup), not related to OOP at all.

The only drawbacks of OOP are:

- It can add complexity when you shoehorn your non-OOP idea into OOP. (Two lists of things can remain as lists. They don't NEED to become fully encapsulated independent objects with getters, setters, that can only be operated on one at a time. A CPU is much faster with lists than singular objects.)

- It's slower. Slower is a hugely relative turn though. 99% of code running modular, or OOP are going to be indistinguishably the same speed. It doesn't matter how long your code takes (1 nanosecond VS 2 nanaseconds) when your code is calling a library / system call that takes 1 millisecond to execute.

Basically, new-comer advice: DO NOT WORRY about speed until it IS a problem. THEN, look first at using the right algorithm (and understand algorithm complexity). THEN after all of that, look at the coefficients which is something OOP is affecting.

There's no point is saving 1 millsecond when the routine takes 1 second to complete.

Battyhal

Thanks for the advice Edgar and Chris. In fact i like OOP (for the moment) because i think makes "abstraction" less "abstract", i mean is easier to think in terms of objects and relations between them than pure "machine thinking" (at least for me ;D).

The article about "algorithm complexity" is translated to spanish also !. Thanks Chris!!.

princeofspace

I'm gonna throw my hat into the ring, perhaps somewhat controversially.

I've found the OOP is not always the best model for games. Sometimes it makes sense, and things like interfaces and inheritance can come it handy.

But sometimes it can get in the way. Mike Acton has discussed data oriented design at some length, which emphasizes programming systems instead of individual objects.

Why? Because in game programming, where there's one object, there's many, and it can make more sense to handle groups instead of individuals. There's a Linus Torvalds quote that helped the quality of my code quite a bit:

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

By thinking about the best design pattern for what you want the game to do, you produce better code.

Edgar Reynaldo

I've found the OOP is not always the best model for games. Sometimes it makes sense, and things like interfaces and inheritance can come it handy.

But sometimes it can get in the way. Mike Acton has discussed data oriented design at some length, which emphasizes programming systems instead of individual objects.

Why? Because in game programming, where there's one object, there's many, and it can make more sense to handle groups instead of individuals. There's a Linus Torvalds quote that helped the quality of my code quite a bit:

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

"Sometimes it can get in the way". Do you have some examples of this? If there's a better way to do things, I'd like to know about it.

"Handle groups instead of objects". That's what compositing is about. Nothing about OOP precludes you from making composite objects.

"Data structures and their relationships". OOP worries about the same things.

I don't see how any of this would dissuade anyone from using OOP. Rather it reinforces the thought of using it.

princeofspace

I wouldn't say OOP is bad in itself, but in games it may not always be the best choice.

This article explains it pretty well.

A quick example would be virtual methods, which is pretty common in OOP culture. Virtual methods are implemented via virtual method tables (vtable for short), in which function pointers are stored. This adds indirection to the call to fetch the address of the function to call from the vtable, then call it, as opposed to just calling it.

Making less work for the CPU at runtime makes sense to me, by focusing on the data instead of arbitrary classes and objects.

That said, my engine does use a sort of interface/prototype system implemented with structs and function pointers, so I may be a hypocrite. :P

Chris Katko

I'm well aware of data-oriented design. And it has no place for beginners still grappling with basic program structure.

Teach OOP first, then show them the few cases where it breaks down and the solutions for those problems.

Edgar Reynaldo

I wouldn't say OOP is bad in itself, but in games it may not always be the best choice.

This article [gamesfromwithin.com] explains it pretty well.

A quick example would be virtual methods, which is pretty common in OOP culture. Virtual methods are implemented via virtual method tables (vtable for short), in which function pointers are stored. This adds indirection to the call to fetch the address of the function to call from the vtable, then call it, as opposed to just calling it.

Making less work for the CPU at runtime makes sense to me, by focusing on the data instead of arbitrary classes and objects.

That said, my engine does use a sort of interface/prototype system implemented with structs and function pointers, so I may be a hypocrite. :P

"This article ... explains it well". All I seemed to get out of that article was to use arrays and not trees. That still doesn't preclude object oriented programming. There's nothing stopping you from processing large sets of data in parallel in OOP.

"Virtual methods". I agree vtables can be a performance hindrance due to cache misses and indirection, but if you're smart you don't use inheritance in performance critical code. Again, nothing to do with OOP here. Also, be aware that premature optimization can kill your project with wasted time focusing on non-issues.

"Focusing on data". Nothing you can't do with OOP.

"Structs and function pointers". Jump tables are not as bad as you might think. If you keep the function code in the cache, the cpu can probably process it fairly easily.

So I don't see how "Data Oriented Design" conflicts with using OOP. They aren't mutually exclusive, as the article seems to imply.

princeofspace

I'm well aware of data-oriented design. And it has no place for beginners still grappling with basic program structure.

Teach OOP first, then show them the few cases where it breaks down and the solutions for those problems.

This touches on an interesting discussion that I think might go beyond the scope of this thread. When I was learning to code, I wish I'd known more about other design paradigms because I think it would've helped me to solve problems in different and novel ways. Learning OOP first may have an advantage in that 90% of the code on the Internet is OOP.

So I don't see how "Data Oriented Design" conflicts with using OOP. They aren't mutually exclusive, as the article seems to imply.

There's probably some truth to this. My engine does use some OOP style code, but it's not exactly entirely OOP.

What really helped me is what Mike Acton calls "back of the envelope" calculations. Take a hard look at what you want your game to do. What can you do to write the code around the data, and not the other way around?

Thread #616396. Printed from Allegro.cc