GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Gliese: Gamedev Support Library Page Previous  1, 2, 3
View previous topic :: View next topic  
Author Message
NyanNyanKoneko
Contributor

Joined: 19 Oct 2005
Posts: 450
Location: In your L1 CPU cache
PostPosted: Fri Dec 14, 2007 9:37 am    Post subject: Reply with quote

You're right. Scratch that idea. Gliese comes with a linked list structure already, and C++ has STL.
View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4977
Location: Silicon Valley!
PostPosted: Fri Dec 14, 2007 9:45 am    Post subject: Reply with quote

Well, maybe you could have the draw list functionality that takes in some of these predefined structures (or at least the Gliese internal one).
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
n29
Developer

Joined: 13 Sep 2005
Posts: 879

PostPosted: Sat Dec 15, 2007 8:30 am    Post subject: Reply with quote

Hmmm, this drawing list is sounding awefully lot like, oh I don't know, a scenegraph?

:P
View user's profile Send private message
NyanNyanKoneko
Contributor

Joined: 19 Oct 2005
Posts: 450
Location: In your L1 CPU cache
PostPosted: Sun Dec 16, 2007 10:16 pm    Post subject: Reply with quote

It's nothing like a scenegraph! Gliese has no nodes. Gliese uses links!
View user's profile Send private message Visit poster's website
NyanNyanKoneko
Contributor

Joined: 19 Oct 2005
Posts: 450
Location: In your L1 CPU cache
PostPosted: Wed Dec 19, 2007 3:25 pm    Post subject: Reply with quote

Actually, after using XNA, I wonder if it might be a good idea to switch to C++ because IDEs will be able to use code-completion...

There will be no inheritance though. The biggest thing I dislike about C++ libraries is when your objects inherit. It makes going through the documentation infuriating.

For example, a lot of C++ GUI libs inherit a "RECTANGLE" class early on. So resizing the control is not obvious by browsing the documentation for "button." It's much more intuitive for libraries to have-a instead of be-a. I really want Gliese to be straightforward. All the functions relating to textures should be listed under "textures" in the documentation.

I wonder if C supports static functions within a struct... hmm...

EDIT: Nope, just function pointers. Blah. OK. I'll stick with what I was doing. The last thing a fast library like Gliese needs is to resolve function pointers every time you use a struct.
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10781
Location: Canadia
PostPosted: Wed Dec 19, 2007 3:50 pm    Post subject: Reply with quote

Not to mention, having to store an extra pointer per function.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
NyanNyanKoneko
Contributor

Joined: 19 Oct 2005
Posts: 450
Location: In your L1 CPU cache
PostPosted: Wed Dec 19, 2007 4:02 pm    Post subject: Reply with quote

It would just be a vtable done in C, but we all know that virtual functions suck when performance matters.
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10781
Location: Canadia
PostPosted: Wed Dec 19, 2007 4:40 pm    Post subject: Reply with quote

Ah yes, still 1 too many. Which makes C++ nice 'cause you don't need any, unless you're silly enough to make something virtual. :)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Madgarden
Contributor

Joined: 31 Aug 2005
Posts: 324
Location: Kitchener, ON, CA
PostPosted: Thu Dec 20, 2007 11:51 am    Post subject: Reply with quote

Huh? This "C problem" with static struct members is a non-issue. You're trying to use the struct as a sort of namespace. Don't. Use the "static" function name itself as the namespace.

Really, there's no mystery here... just some C++ brainwashing to overcome. ;) If you don't need to use a vtable, then don't! C++ static members are just funkily named global file-scoped C-style functions, essentially. Same goes for static data. This is all standard fare for C:

Code:

/* Class-scoped C++ *function* with a long-winded name*/
CFoobar::staticCeePlusPlusMethod(1, 2);

/* function "class-scoped" by name... it's just a function, people */
foobar_cee_static_function(1, 2);


There's no "this" pointer being passed in either, so the struct/object association requirement above is not what you want here. You can still pass in a struct/struct pointer if you wish of course, and in fact this is what you should do for performance purposes, especially if you're not wanting polymorphism. Data inheritance using "has-a" embedded structs is there, if you want that.

And BTW, C++ is *not* nicer! Hells no. :p In fact I find it funny that static methods are somehow some kind of black ooga booga non-object magic weirdness in C++, whereas in C it's the most basic feature: a function.
_________________
I know it sounds crazy, but it JUST MIGHT WORK
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10781
Location: Canadia
PostPosted: Thu Dec 20, 2007 4:39 pm    Post subject: Reply with quote

Ya ha ha! C++ battle on!!!1 :D

Quote:
Really, there's no mystery here... just some C++ brainwashing to overcome. ;) If you don't need to use a vtable, then don't! C++ static members are just funkily named global file-scoped C-style functions, essentially. Same goes for static data. This is all standard fare for C:

Exactly. But the idea of a "this*" is common enough even in C, that it is a useful and space saving feature. No vtables required.

Code:
int Value = Awesome_ConvertToInt( MyAwesome );
int Value = MyAwesome.ConvertToInt();


C static problem, I wasn't even aware of a problem. :)


The bulk of C++ features, as I see them, are organization improvements.

Namespaces are a means to multiple global scopes, where you can safely mix and match functions and types of the same name. It's great that the STL stuff lives in the STD namespace, so I can waltz right in and rewrite the standard global functionality, or place nice if I choose to. Don't care? Don't use 'em.

Classes, I find it hard to see raw classes as worse. Even C++ structs, if you prefer not to use public and private scope, you can. And take advantage of being able to include "this*" concept functions in a class. Sure, you can do the same thing with underscore naming, but there's something to be said for the clarity of "Me.Blah()" syntax over "MyType_Blah( Me );". This function does something with the contents of "Me". If it's a Screen, and the function is DrawLine, it's fair to think it draws a line on the screen.

Operators!
Code:
v.x = v1.x + v2.x;
v.y = v1.y + v2.y;
v.z = v1.z + v2.z;

No!
Code:
v = v1 + v2;

Done! Why type all that all the time? When you need to get specific, get specific. But 99% of the time, you just wanted to add.

Function name overloading! Have a 2 argument operation where "this*" functions look wronig? Write a global function for your operation. "float Dot( vec3d, vec3d );". No problem. Oh no! I need a 2d version! "float Dot( vec2d, vect2d );". No problem.

Even C++ free placement of variables. C forcing you to declare a variable at the top. That's not helpful, especially if it's meaningless until later in the code. You can get around this problem with scope brackets, but not always.


And by using just them, there are no overheads introduced over C code. No secrets. I honestly don't see any advantage living with the "unfinished" features of C. If you don't trust constructors and destructors, don't use 'em. If you don't trust new and delete, don't use 'em.

As languages go, C++ is one of the kindest upgrades available. You can use only 1 feature, and you're better off than you were with C.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
NyanNyanKoneko
Contributor

Joined: 19 Oct 2005
Posts: 450
Location: In your L1 CPU cache
PostPosted: Thu Dec 20, 2007 5:08 pm    Post subject: Reply with quote

Quote:
Namespaces...


Agreed.

Quote:
Operators!


Sometimes overloading operators makes sense, other times it doesn't. Most of the time though, overloaded operators become cryptic. Is Vector * Vector a dot product or a cross product? What does vector<int> < vector<int> compare? Why is the bitshift operator used to output text? It makes no sense! Well, it kind of does, but not as much as printf() which clearly defines itself.

Operators in C always behave in the same manor. That consistency is important in keeping things simple.

Quote:
You can use only 1 feature, and you're better off than you were with C.


Except then you're not compatible with C, and with the exception of namespaces, there's nothing you "need in C++." Similarly, simply because something is there doesn't mean you're better off using it. Every new feature adds a level of complexity to the language. This sort of falls into the "more features = better" programming mentality I was talking about in another thread.

Don't get me wrong. I love C++, it's just that it gets misused a lot, particularly in relation to libraries. Instead of simplifying code you end up complicating things. WIth my goals of keeping gliese simple, fast, and easy to use, C is the perfect language.
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10781
Location: Canadia
PostPosted: Thu Dec 20, 2007 5:39 pm    Post subject: Reply with quote

NyanNyanKoneko wrote:

Quote:
Operators!


Sometimes overloading operators makes sense, other times it doesn't. Most of the time though, overloaded operators become cryptic. Is Vector * Vector a dot product or a cross product? Why is the bitshift operator used to output text? It makes no sense!

Agreed. Even component wise multiplication in meaningful (vectors as color). That's where function name overloading is nice, because you can omit class specifics from a long name, letting the arguments dictate what version is called, and go with a general interface.

Personally, I'd prefer named operators ( Vec = Vec1 DOT Vec2; ), but functions do just fine.

Quote:
Quote:
You can use only 1 feature, and you're better off than you were with C.


Except then you're not compatible with C, and with the exception of namespaces, there's nothing you "need in C++." Similarly, simply because something is there doesn't mean you're better off using it. This sort of falls into the "more features = better" programming mentality I was talking about in another thread.

I agree, but just as more features != better, fewer features isn't better either. No matter the situation, there's always a balance. Coding with a macro-less assembler strikes me as a waste of time. You need tools. How uninformed code noobs work isn't a very good reason to abandon perfectly useful and high benefit features. Use them better.

C style has it's place. To me, it's in the foundation. Most of my low level library code (non math) is both. It's broken in to C functions, with an optional class that integrates everything. But my time is important, so I don't waste it with C style variable scope, or extern C, and other compatability. There is not a reasonable target platform out there anymore you can't get a C++ compiler for. C isn't a language to me anymore, as it is a style of implementation. If, and I stress if, it was important, porting the code to straight C would only be a half hour to an hour of work. Realistically speaking, it will not come up. Not anymore.

And as far as actual game implementations are concerned, C compatibility is not a concern.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
NyanNyanKoneko
Contributor

Joined: 19 Oct 2005
Posts: 450
Location: In your L1 CPU cache
PostPosted: Fri Dec 21, 2007 9:55 pm    Post subject: Reply with quote

Performing transformations (rotation, scaling, translation) on a quad:

Code:

GS_MATRIX transform_matrix;
GS_QUAD test_quad;
GS_QUAD test_quad2;

...

/* Via Matrix */
gs_set_matrix_to_identity(&transform_matrix);
gs_multiply_scaling2d_matrix_to_matrix(0.75f, 0.75f, &transform_matrix);
gs_multiply_rotation2d_matrix_to_matrix(rotation_degrees, &transform_matrix);
gs_multiply_translation2d_matrix_to_matrixf(0.5f, 0.5f, &transform_matrix);
gs_setup_quad2d_from_texture(&transform_matrix, texture, &test_quad);

/* Via Direct Manipulation */
gs_setup_centered_scaled_quad2d_from_texture(0.0f, 0.0f, 1.0f, texture, &test_quad2);
gs_rotate_quad2d(rotation_degrees, &test_quad2);
gs_scale_quad2d(0.75f, 0.75f, &test_quad2);
gs_translate_quad2df(-0.5f, -0.5f, &test_quad2);
        
gs_render_quad2d(&test_quad);
gs_render_quad2d(&test_quad2);


The matrices multiply in proper order unlike in standard OpenGL where transformations are multiplied in reverse order. So unlike OpenGl where the last thing you multiply the matrix by is the first that that gets transformed, the first thing you transform a GS_MATRIX by is the first thing that happens to the matrix.

So if you want to rotate, scale, and then translate, in Gliese you call those in order. In OpenGL the default is to call them in reverse order which is no good. :(

View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4977
Location: Silicon Valley!
PostPosted: Sat Dec 22, 2007 5:44 am    Post subject: Reply with quote

Oh, nice! It was always annoying to wrap your brain around how the matrix operations happened in OpenGL. I think if anything, you're definitely going to need a good example program/tutorial that explains this to the user of Gliese.

I noticed that your functions names are pretty explicit (self explanatory) in what they do, which is very nice; but damn, they are really long!
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
Madgarden
Contributor

Joined: 31 Aug 2005
Posts: 324
Location: Kitchener, ON, CA
PostPosted: Sat Dec 22, 2007 6:58 am    Post subject: Reply with quote

I mapped all of that sort of stuff to my "turtle" interface in Saucelifter, which made it completely intuitive. You might consider something similar... it would also vastly decrease your API.
_________________
I know it sounds crazy, but it JUST MIGHT WORK
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger
NyanNyanKoneko
Contributor

Joined: 19 Oct 2005
Posts: 450
Location: In your L1 CPU cache
PostPosted: Sat Dec 22, 2007 7:38 am    Post subject: Reply with quote

Madgarden, please explain. :)
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Gliese: Gamedev Support Library Page Previous  1, 2, 3

Use this link to get a Sign-On Bonus when you get started!

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.