Sign in to follow this  

Game Engine Discussion

This topic is 2783 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys. I've been working on a game engine for almost 2 years now and since in half an year or so I want to publish it I'd like you to take a minute and talk a bit about what you like and what you don't. (Preferrably from the programming point of view). First of all what style of programming do you like in a library? Procedural or OOP?(DrawImage(image,x,y) or image->Draw(x,y)) Do you care more about 2D or 3D? If a game engine would only be 2D at least at the beggining would you show some intrest(provided it's of a good quality)? How much does the documentation help and how much does the on forum support help? How does a "all game-engine related questions are answered within 24 hours" policy sound to you? For a 2D engine that has the following features how much would you pay? Features: OpenGL and DirectX renderer Cross platform(only OpenGL for platforms other than Windows) Sound support Resource manager Very fast per pixel collisions and as well as bounding box collisions. Physics Advanced effects such as motion blur, shaders (yes for 2D). Tools for asset creation.(the engine supports a new sprite format based around png that's developed with game creation in mind and thus supports a smaller file size, animations,transparency etc). Interface system with a skin designer and a general designer (much like the way .Net has) LUA Scripting support. For a 3D renderer what kind of renderers would you like? Forward, Deferred or Both? Would you like to have allready created post processing effects like motion blur, ssao, volumetric light scattering etc? Do you consider shadow-mapping to be the best shadow system for game rendering? If the engine has it's own 3D format what's more important, plugins for 3D Max and Maya or general converters (stand alone)? Finally how should a simple program that loads a image and draws it should look in your opinion? Do you consider the following to be easy to use?
#include "Engine.h"

void main()
{	
	InitializeEngine();//Load all the engine functions from the dynamic library

	CreateEngineWindow(1024,768,32,DEVICE_GL);// Create the engine 
						//in it's own window. CreateEngine(handle) 
						//can be used to attach it to a existing 
						//control in a window
	TImage img = LoadImage("image.png");//Load a simple image

	while(!KeyDown(KEY_ESCAPE))
	{
		Cls();//Clear the screen
		SetScale(2,1);//Set the scale that the next 
				//images will be drawn with(optional)
		SetRotation(45.0f);// Set the rotation that 
				//the next image will be drawn with(optional
		DrawImage(img,256,256);// Draw the actuall image using the supplied 
					//scale and rotation
		Flip();//Switch the front buffer with the backbuffer
	}
}

Share this post


Link to post
Share on other sites
Quote:
Original post by LorinAtzberger
First of all what style of programming do you like in a library? Procedural or OOP?(DrawImage(image,x,y) or image->Draw(x,y))

Procedural versus object oriented is a major design decision that has to be made at the very beginning of a project. This is not something that you just change like that on the last minute. You said that you have been working for two years on your engine, so this decision has already been made a long time ago.

Quote:
Original post by LorinAtzberger
How much does the documentation help and how much does the on forum support help?

Documentation is absolutely vital. I'd go as far as saying that good and up-to-date documentation is far more important than the technical features of an engine. Forum support is an optional bonus.

Quote:
Original post by LorinAtzberger
How does a "all game-engine related questions are answered within 24 hours" policy sound to you?

Mostly irrelevant, unless we're talking about a commercial product (which we are not, see below). In a commercial context, giving such a guarantee is very dangerous, unless you know exactly what you're doing - ie. you have the staff to actually be able to commit to it, and you're ready to face possible legal action if something happens to take 25 hours.

Quote:

For a 2D engine that has the following features how much would you pay?
Features:

Nothing at all. Let's be realistic. Such an engine would have absolutely no commercial value. Countless engines offering these features are available for free all over the net. Engines offering much more than this are also available for free, with huge user bases and proven quality track records.

If you want people to actually use it, then you'll have to release it for free. And even then, there is no guarantee that it won't just go unnoticed in the vast sea of indie engines out there. You are facing an extreme competition on this 'market', with a product that has no real monetary value. You will have to build up such value, and that is a very slow and difficult process. And it fails in easily 99.9% of all cases.

Ironically, the most realistic way to make an indie engine somewhat commercially successful is that you pay someone to make a successful game with it.

Quote:

For a 3D renderer what kind of renderers would you like? Forward, Deferred or Both?

Irrelevant. Settle for one type (or a hybride), make sure that it is supported by the HW you target, and make sure it supports all visual effects you'd like to expose. As long as the visual result is correct, it is extensible and the targeted range of hardware is adequately supported, the underlying rendering technology doesn't really matter.

Quote:

Would you like to have allready created post processing effects like motion blur, ssao, volumetric light scattering etc?

Of course, if they're in the list of supported out-of-the-box effects.

Quote:

Do you consider shadow-mapping to be the best shadow system for game rendering?

Impossible to answer. "Game rendering" is an extremely wide and blurry field. Shadow mapping (or better one of its countless derivates, since raw shadow mapping is mostly unusable) is well suited for a certain range of usage scenarios. It is less suited for others. Position yourself where exactly you want to go and select the right tool for the job.

Share this post


Link to post
Share on other sites
Okay, you are not helping at all. Just saying "You will fail" is not really nice.
I'm asking about procedural vs OOP because I want to know what interface to make. The engine is allready made using OOP but right now it gives a procedural interface (read about exporting C++ classes in dll's and you will know why I'm saying this).
Yes documentation is absolutely vital and I agree with you when you say up-to-date documentation is maybe more important than a big number of technical features.
Yes it might be a bit too much saying that all questions are to be answered within 24 hours but I for one at least want to try.
If you say countless engines are allready offering this for free then please name one that offers all those features and it's actually easy to use.(Really.. I mean it)
I want to make a series of great demos to show the engine's power. That should show people that I really take this serious. I for one have been changing engines and (commercial and free) just to find out that none is actually that great and easy to use for intermediate experienced indie. The only one I kinda like is BlitzMax but many people are afraid to use it just because it's not C++. On the other hand the way it works is great. Another downside is that it only has a 2D engine.
For the 3D renderer asking about about prefferences between forward and deferred is not really irrelevant. There are advantages and disadvantages on both. My engine currently has a both renderers in it. Deferred is great on new machines while forward is a good fallback for older machines on which games might run on.
Yes, shadow-mapping might have been a much too general term. I was thinking of variance shadow-mapping when I asked that.

I see you left out the last question and makes me wander why since you answered all of the other questions.

I'd like some people to answer the questions as if this were to be their "Dream-Engine".

Another thing I'm thinking of is to offer the engine free with no strings attached to a limited number of people just to make it known by developers.

Thanks.

Share this post


Link to post
Share on other sites
What are you using for physics? Also, what platforms do you plan on targeting?

One quick comment on this line of your sample code:
Cls();//Clear the screen
There's really no reason to use abbreviated function names like that. I know it's just an example, but note that if you spelled out the function name in full, the resulting line:
ClearScreen();
Would be shorter overall, and no comment would be necessary. (In your existing code, you basically have a cryptic function call followed by a comment that's only necessary because the function name is abbreviated.)

Anyway, I certainly don't want to be discouraging here - if you have the time and technical knowledge and resources to create an engine that can compete with other similar free and/or commercial engines that are currently available, then more power to you. I will however admit to a certain degree of (healthy, I think) skepticism, simply due to the quality of the similar engines that are already available and the sheer number of man-hours required to create something of the scope you're describing,

If you haven't already, I'd recommend surveying some of the other similar engines and authoring tools currently available, such as Unity, Shiva, Quest3D, and so on. It does seem to me that there's a move towards RAD tools such as Unity and Shiva underway right now, and as such, it may be that a (comparatively) low-level C++ engine might have somewhat limited appeal (perhaps even more so by the time you actually get it finished). If you plan to release it for free, then it may not matter that much whether it finds an audience, but if you're hoping to sell it, I'd definitely do a careful survey of other similar engines and tools (both free and commercial) just to make sure that what you have in mind really has something to offer above and beyond what's already available (to the extent that people will actually pay to use your engine rather than one of the similar existing and established engines).

Share this post


Link to post
Share on other sites
For physics it's yet undecided between Newton and Havok. I played with both and they both seem to be nice. I tend to like Havok more but I still have to think about their liceense system.

It just seems longer to write ClearScreen(); than Cls();. Think about the fact that one you will get used to the engine you will no longer need comments for the intstructions. I mean even if I hadn't wrote the comment you would have still understood what that line did right?. I added those comments just to be even more clear altough it seems to me that it's preety much straight-forward.
I don't really feel that function names are abbreviated. take for instance DrawImage or LoadImage. I really don't think a function that would sound like LoadStaticImageFromHardDisk would seem appealing. Don't get me wrong I do get your point and I am taking it in consideration.

I understand what you are saying about RAD tools and frankly I too want to go in that direction but first I need some good core components to further expand in that direction. My dream is to be a middleware creator. Basically I release this 2D engine and take it to a good point in development and after that I start working on a tool like GameMaker (sort of). Both will be on sale based on what the user wants. It's always more flexible to use an engine as a library than as a RAD tool but it's also slower. It all comes down to what the user wants.
I for one played with Unity and didn't really like it but I will try Shiva as well to see what's it about.

Every engine out there started in a way right? Most projects that don't go too far die just because the developer looses interest. I lost interest in many game related projects and that's usually because I didn't have graphics and general funds. Developing middleware is cheaper and you can focus on the programming of components rather than making character A follow character B.

Thanks for the answer.

Share this post


Link to post
Share on other sites
Let me start by apologizing for my negative tone. I only mean to point out the challenges, as I see them, in what you are doing. Hopefully you can overcome them and produce a better product.

Quote:
Original post by LorinAtzberger
Okay, you are not helping at all. Just saying "You will fail" is not really nice.

If I were you I would re-read Yann L's post. He wasn't saying "you will fail" and was definitely trying to help by giving you some good feedback. He explained his view on documentation, why he thinks the "help within 24 hours" is dangerous, why he doesn't think people would pay for such an engine and so on. If answering your questions isn't "nice" then how can you get feedback? Anyway, you asked for feedback and somethimes "you will fail" is indeed the most realistic feedback and you can do one of three things: try and prove everyone wrong and continue anyway, give up or listen to what everyone has to say and adapt your product.

Quote:
Original post by LorinAtzberger
I'm asking about procedural vs OOP because I want to know what interface to make. The engine is allready made using OOP but right now it gives a procedural interface (read about exporting C++ classes in dll's and you will know why I'm saying this).

I'm certain Yann L already knows this. I don't know if they still exist, but a number of years ago, Yann released some absolutely amazing (for the time) screenshots from his engine. So when it comes to graphics engines, he knows what hes talking about.

Quote:
Original post by LorinAtzberger
If you say countless engines are allready offering this for free then please name one that offers all those features and it's actually easy to use.(Really.. I mean it)


You didn't list many features and your sample code is very simplistic, so I'll list libraries and engines which support what you said to varying degrees:

SDL, GLFW - similar to your sample code. Lots of extension libraries out there. Excellent documentation and large communities.

Allegro, ClanLib, Haafs Game Engine - easy to use 2d game engines

SFML - easy to use 2d/3d game engine, seems similar to what you're proposing.

Pyglet, Pygame - very very easy to use game libraries, if you don't mind using Python.

OGRE, Horde3D - advanced 3D rendering engines

Irrlicht, Blender3D game engine, Panda3D, Nebula Device - complete game engines


There are also countless hobby engines out there and a lot of high quality commercial ones (if you can afford to license them). Basically, the market you are trying to enter is highly monopolized by the big players, free or commercial and its very dificult for new game engines to gain much recognition. As an exercise, do a google search for people talking about their awesome new game engine that will dominate the market here on gamedev.net. As someone whos spent a lot of time learning about startups, working on one myself and hanging out with other startup founders, I do not believe that a commercial game engine for indie developers is a good bet. You're mileage may vary, of course and I do wish you the best of luck and apologize that my post is so negative. I only hope to be realistic.

Quote:
Original post by LorinAtzberger
For the 3D renderer asking about about prefferences between forward and deferred is not really irrelevant. There are advantages and disadvantages on both. My engine currently has a both renderers in it. Deferred is great on new machines while forward is a good fallback for older machines on which games might run on.


For, as you put it, "intermediate experienced indie" finds the masses of other engines out there to be too dificult to use, then chances are the forward vs deferred renderer question may be irellevant to them too, but thats just my opinion. I would say pick whichever _you_ feel would let you accomplish the desired features which you wish to support.

Quote:
Original post by LorinAtzberger
I see you left out the last question and makes me wander why since you answered all of the other questions.


I think your sample code is much too complicated. It adds very little value over using libraries like SDL, GLFW, Allegro, ClanLib, Pyglet or engines like Haafs Game Engine, Irrlicht, Horde3D, Panda3D etc etc, all of which have excellent documentation, large userbases, a lot of development/testing/debugging time and effort has been put into them (many many years, in some cases) and are free.

Quote:
Original post by LorinAtzberger
Another thing I'm thinking of is to offer the engine free with no strings attached to a limited number of people just to make it known by developers.

Do whatever you feel is worthwhile to market your engine. If the engine really does provide some edge over the alternatives (easier to use, better featureset, whatever) then any additional exposure you can get is good and if your engine doesn't provide anything meaningful over the competition, then it doesn't really matter what you do.

Also, I would like to say that I (and others here) consider developing game engines without games dangerous (instead, dveelop games and adapt the code until its an engine) because otherwise you end up with an engine which feature-wise and tutorial/sample code-wise is very nice, powerful and simple, but when you try and actually write complete games in them you relaise that its actually very dificult. Its very easy to get lost in your work and forget about the end-user. By writing the games first and adapting and reusing code which over a number of games is turned into an engine (I would say you should then go back and refactor the previous games to use the engine), then you have a well tested and proven engine, instead of having to hope that you do.

In any case, I wish you the best of luck and hope you can pull it off and produce a kickass engine.

Share this post


Link to post
Share on other sites
Quote:
I understand what you are saying about RAD tools and frankly I too want to go in that direction but first I need some good core components to further expand in that direction. My dream is to be a middleware creator. Basically I release this 2D engine and take it to a good point in development and after that I start working on a tool like GameMaker (sort of). Both will be on sale based on what the user wants. It's always more flexible to use an engine as a library than as a RAD tool but it's also slower. It all comes down to what the user wants.
Sure, that makes sense (in any case, even RAD tools such as Unity have a C++-based engine under the hood).
Quote:
It just seems longer to write ClearScreen(); than Cls();. Think about the fact that one you will get used to the engine you will no longer need comments for the intstructions. I mean even if I hadn't wrote the comment you would have still understood what that line did right?. I added those comments just to be even more clear altough it seems to me that it's preety much straight-forward.
I don't really feel that function names are abbreviated. take for instance DrawImage or LoadImage. I really don't think a function that would sound like LoadStaticImageFromHardDisk would seem appealing. Don't get me wrong I do get your point and I am taking it in consideration.
Just for the sake of discussion, let me offer some counter-arguments.

I don't know that the argument 'X takes longer to type than Y' holds that much water these days. At least based on what I see in other people's code (including commercial engines) and on these forums, it seems to me that these days clarity and readability are generally favored over saving a few keystrokes here and there, and I really don't see abbreviations like 'cls' being used that often in middleware (at least not in the middleware that I've seen).

In any case, a 'clear screen' function is probably only going to appear in a handful of places in your code, so abbreviating it really doesn't gain you that much typing-wise. As for 'getting used to' the engine, I don't think that's a very useful argument; when I use middleware, I like the syntax to be clear immediately, not just after I've 'gotten used to it'.

As for 'cls', sure, it's pretty easy to venture a guess as to what that means (especially in context). However, if I saw Cls() in someone's code, I'd have to stop and think, consult the documentation, and/or examine the surrounding code in order to figure out what it meant, whereas if I saw ClearScreen() I would have to do none of those things.

Also, I don't think the LoadStaticImageFromHardDisk() example is particularly relevant, as you are comparing a clear, fully spelled-out function name to a rather contrived and overly lengthy name with a lot of redundant information in it, whereas the comparison I was making was between a clear, fully spelled-out name and a somewhat cryptic three-letter abbreviation.

Anyway, you already said you were considering the point, so I suppose all of the above probably wasn't really necessary. I do think clear code is important though, so I tend to argue for it when I get the opportunity :)

Share this post


Link to post
Share on other sites
I would always prefer clear, well named identifiers over acronyms (unless they are very widely known acronyms like XML), shortened or abbreviated words. It helps readability, it helps understanding, it helps me figure out what the code does at-a-glance. Especially for an engine which, as you've said, aims to be _simple_. Readability is very important here.

As for it saving on typing, this is a useless feature. I type enough every day that an extra few characters here and there make absolutely no difference to me. Thinking about the problem at hand and understanding the code and task takes much more time and effort than typing ut the code anyway, esides, most editors have auto-completion nowadays, so short names are even more useless.

I wouldn't choose an engine which requires me to memorize too many abbreviations. Most likely theres plenty of other concepts I need to keep in mind, nevermind whatever the game I'm trying to write needs, I don't need that additional cognitive load.

I would suggest clear, meaningful but to the point names. So

ClearScreen() instead of Cls()
LoadStaticImage() instead LoadStaticImageFromHardDisk()

If there are different places you could load from, an OOP approach may be useful:
disk->LoadStaticImage()
network->LoadStaticImage()

or namespaces:
Disk::LoadStaticImage()
Network::LoadStaticImage()

To me, these are easy to understand, remember and they show intent.

Just my opinion. Hope its helpful.

Share this post


Link to post
Share on other sites
Quote:
Original post by LorinAtzberger
First of all what style of programming do you like in a library? Procedural or OOP?(DrawImage(image,x,y) or image->Draw(x,y))


It doesn't matter as long as its consistent. What languages do you want to support? If C++, then do the OOP style, if C then obviously the other way.
You could go the route that FMOD took: OOP C++ API with a procedural wrapper for C users. This way the user can choose their preferred way.

Quote:
Original post by LorinAtzberger
Do you care more about 2D or 3D? If a game engine would only be 2D at least at the beggining would you show some intrest(provided it's of a good quality)?

Personally, I'm generally happy enough with 2D, provided the quality is high. This depends on the game and person though. Also, even in 2D, some 3D effects may be desirable.

Quote:
Original post by LorinAtzberger
How much does the documentation help and how much does the on forum support help?
How does a "all game-engine related questions are answered within 24 hours" policy sound to you?

The more documentation and support you can reasonably provide, the better.

Quote:
Original post by LorinAtzberger
For a 2D engine that has the following features how much would you pay?
Features:
OpenGL and DirectX renderer
Cross platform(only OpenGL for platforms other than Windows)
Sound support
Resource manager
Very fast per pixel collisions and as well as bounding box collisions.
Physics
Advanced effects such as motion blur, shaders (yes for 2D).
Tools for asset creation.(the engine supports a new sprite format based around png that's developed with game creation in mind and thus supports a smaller file size, animations,transparency etc).
Interface system with a skin designer and a general designer (much like the way .Net has)
LUA Scripting support.

Feature lists like this don't really tell me much. How much work is required for me to, eg, use motion blur on a character?
The list itself sounds good, but I wouldn't pay for it. As I said in my other post,t heres lots of free engines out there. Most claim similar feature lists. This doesn't mean that you're not on to something, just that you have to find a killer feature or niche that people will pay for. I cant tell you what that is, but this thread may be a good first step into finding out what people want from an engine. You need to do something better than other engines (and find a way of advertising and proving that it is indeed better) or you need a feature that other engines dont have. Maybe you already have this - you need to persuade your target market somehow.

Quote:
Original post by LorinAtzberger
Finally how should a simple program that loads a image and draws it should look in your opinion?

I would like something where I can define the game objects/characters/entities, behaviours and the scene and the engine manages it for me. Off the top of my head, perhaps something like this:

[source language="cpp"]
clude "Engine.h"

void main()
{
Engine engine(1024,768,32,DEVICE_GL);
Scene* scene = engine->newScene();
Image* image = new Image("image.png");
scene->addImage(image, new Scale(2, 1), new Rotation(45.0f));
engine->addAction(new KeyTrigger(KEY_ESCAPE), new QuitAction());
enigne->run();
}



...though I didn't put much thought into it.

Share this post


Link to post
Share on other sites
The engine is written in C++ but I currently have ways to use it in C/C++ and C#(I wrote a wrapper).
I'll first start with the 2D engine and make sure that that one is very clear, bugless and has some advanced features that other engines don't offer.

I don't want to be mean but neither of the engines you guys told me about offers what I said. If I mean to get this engine finished you'd think that by now I'd know the competition.


void main()
{
Engine engine(1024,768,32,DEVICE_GL);
Scene* scene = engine->newScene();
Image* image = new Image("image.png");
scene->addImage(image, new Scale(2, 1), new Rotation(45.0f));
engine->addAction(new KeyTrigger(KEY_ESCAPE), new QuitAction());
enigne->run();
}


This seems a lot more complicated to me than my ideea of simple code.

Share this post


Link to post
Share on other sites
Quote:
Original post by LorinAtzberger
void main()
{
Engine engine(1024,768,32,DEVICE_GL);
Scene* scene = engine->newScene();
Image* image = new Image("image.png");
scene->addImage(image, new Scale(2, 1), new Rotation(45.0f));
engine->addAction(new KeyTrigger(KEY_ESCAPE), new QuitAction());
enigne->run();
}

This seems a lot more complicated to me than my ideea of simple code.



Then how would you like the above code snippet (or did I get it wrong?)?

Share this post


Link to post
Share on other sites
I'm not sure what you mean so I think I might have got it wrong. That's a sample code not written by me. Mine is on the first post.
Here are some flaws with that design:
Rotation and scale are kept with yeah image in the so called scene. If I have 100.000 images in the scene (not necesarrly on screen) it adds some memory usage. Morehowever this mean that the transformation matrix is automatically calculated for each image in the scene.
From my point of view there is not "scene" it's a useless ambigous term that each game needs in a unique way. You load a image into the memory and if you want to draw it 5 times you just call DrawImage 5 times. What you are saying is some sort of persistent image which in many ways is not the right thing to do since it screws up flexibility a lot. The so called action system also kills flexibility.
What you are saying is more like a game framework that should stay on top of an engine. A great ideea but not actually for the engine itself. I will however consider something like this though.

Share this post


Link to post
Share on other sites
Quote:
Original post by LorinAtzberger
Here are some flaws with that design:
Rotation and scale are kept with yeah image in the so called scene. If I have 100.000 images in the scene (not necesarrly on screen) it adds some memory usage.

So how were you planning to keep track of rotation and scale for individual sprites?

Quote:
Morehowever this mean that the transformation matrix is automatically calculated for each image in the scene.

That's an implementation detail. You could, of course, provide a more restricted, optimized version of that Image class (I'll call it Sprite - an object that contains a position and that references image data).

Quote:
From my point of view there is not "scene" it's a useless ambigous term that each game needs in a unique way. You load a image into the memory and if you want to draw it 5 times you just call DrawImage 5 times.

Or you create 5 Sprite objects - that keep track of position, rotation, scale, alpha, color, and whatever else that would be useful - and tuck them under the current scene. You're going to have to 'configure' those draw calls anyway, so why not automate it?

Quote:
What you are saying is some sort of persistent image which in many ways is not the right thing to do since it screws up flexibility a lot. The so called action system also kills flexibility.

Well, your approach is definitely more tedious to work with, due to all the things I'd have to keep track of manually. How exactly would issch's approach kill flexibility?

One thing that I value greatly in engines/frameworks/libraries is ease of use. Flexibility is good for when I need it, but should ideally not be forced upon me when I don't need it.


As for your custom image format, does your engine also support 'standard' formats, such as .png, .jpg, .bmp, .tga?

Share this post


Link to post
Share on other sites
Basically I just call SetRotation or SetScale or SetColor etc.. before drawing a image if it's needed. If 10 images are using the same transformations then why calculate it again. Just use SetRotation and SetScale once then use that transformation for each of the 10 images.

The main ideea is that it's not a sprite. It's an image. That format of mine is the container of the Sprite which is a different object. It does provide a easier control.

Hm.. Why not automate it. You might want to draw some objects in a weird way. Bundle more images on one object. If you keep creating a sprite for each one it just becomes overloaded.

Anyway I will keep in mind the thing with the framework. However first the engine then the framework.

Yes it supports even photoshop files. I use FreeImage so every format it offers my engine offers as well.

Anyway I really like this topic so please keep posting. I may deny some of your points but I still keep them in mind :)

Share this post


Link to post
Share on other sites
Mostly criticism, but that's the way of evolution :)

Quote:
Original post by LorinAtzberger
Basically I just call SetRotation or SetScale or SetColor etc.. before drawing a image if it's needed. ...
That reminds me of the immediate mode GUI stuff, and it'll suffer from the same disadvantages.

Quote:
Original post by LorinAtzberger
... If 10 images are using the same transformations then why calculate it again. Just use SetRotation and SetScale once then use that transformation for each of the 10 images.

Why should I deal with 10 images all with the same transformation? They will overlap each other, and in the end only 1 is visible ;P

If you want to be able to change only parts of transformations while keeping others, then a kind of state memory is needed. Such a mechanism disturbs the locality of code: I cannot place an image without either having knowledge about the state or else driving the state memory useless because I set the entire transformation anyway.

Looking at the cycle of a typical game loop, I see distinct places where control and where rendering happens. That means for your example of writing transformation stuff close to the rendering stuff that those transformation invocations are to be fed by data calculated previously, compelling me to touch those things twice where otherwise one touch would have been enough (remember the mention of immediate mode GUI above).

BTW: I second jyk's comments on abbreviated function names. And how does your "immediate transformation mode" not contradict the "less typing by abbreviating function names idea"?

Share this post


Link to post
Share on other sites
It's generally not the same thing as immediate mode GUI. Basically you have images here and only images. And by transformation I only mean scale and rotation leaving the position outside of this business.
Quote:
And how does your "immediate transformation mode" not contradict the "less typing by abbreviating function names idea"?

I really don't see how these are related.
I forgot to mention that I used to teach game development here in my town and thus I got used to making user friendly code. At one point I was teaching BlitzMax which has a command set roughly just like mine. (actually I was inspired by it) and my "students" understood that code very easily.

Quick question: Do you guys like Radians or Degrees more? I tend to think degrees are easier to understand but I'd like some second opinions.

Share this post


Link to post
Share on other sites
None that actually got published. But that's not my fault since projects were canceled about 75% of the development time. I was thinking of completing them myself and finding publishers but I'm not legaly allowed to do that.

Share this post


Link to post
Share on other sites
Quote:
Quick question: Do you guys like Radians or Degrees more? I tend to think degrees are easier to understand but I'd like some second opinions.
I'd vote for radians, with conversion functions that can be used where necessary.

Most math libraries work with radians, and many computations involving angles only make sense with radians, so using radians internally seems like it would be more convenient and consistent to me. If degrees are needed (e.g. for a user interface element), the value can be converted to radians as needed.

There are some APIs that use degrees, such as (some of the deprecated parts of) OpenGL, but personally I think radians is the more logical choice.

Share this post


Link to post
Share on other sites
Quote:
Original post by LorinAtzberger
I use radians internally but I was just thinking of the end user.
I think I'll go with radians and add some functions like Rad2Deg and Deg2Rad. Should be easy to understand.

You could also make classes for radians and degrees and let the C++ type system enforce your design choice for free.

Share this post


Link to post
Share on other sites
class Radian
{
public:
Radian(); // Default
Radian(float val); // Does what it looks like
explicit Radian(const Degree& degrees); // Auto-converts from degrees

float ValueRadians() const; // Get value in radians
float ValueDegrees() const; // Get value in degrees
void Set(float val); // Set value in radians

// Operators and such...

private:
float mVal;
};

Degree would look similar.

Share this post


Link to post
Share on other sites

This topic is 2783 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this