411 replies to this topic

[lonegraywolf]

wchar_t...haven't used it much, but isn't that useful for unicode strings? If so, perhaps we should consider it. We have people all over the world that play this game...may as well offer it to the masses.

If a font is requested to allow for unicode properly, I've got one handy. The terms should allow its use.

[Christian]

So with wxWidgets, it'll be possible to have multiple windows open for each type of editor correct? Will it differ greatly from the ZQuest editor we know today?

The whole idea of everything being script supported, like enemies and other non-hardcoded things, doesn't seem to be newbie-friendly though.

Edited by Christian, 04 July 2010 - 08:24 PM.

[Bourkification]

The whole idea of everything being script supported, like enemies and other non-hardcoded things, doesn't seem to be newbie-friendly though.

If you read the thread you would have found out that the scripts will only control game specific things. Everything will still be done through the GUI. The only thing a person should have to do is load a script package.

[lonegraywolf]

Just a quick update: SFML seems to be set up right, while I'm having problems building a universal binary for wxWidgets. I know this should be possible...probably just making a silly mistake. This shouldn't slow me down too much.

[Gleeok]

Actually, I'm kind wondering how LTTP scrolling would work. Could someone explain?

Sure, no problem. Here you go:

CODE

Matrix m = Matrix::CreateTranslation( pos );
glMultMatrixf( &m );

..I kid, I kid... But seriously.

Wait until you get into pointers! Those will give you massive headaches- especially when tracking down memory leaks and junk pointers. Despite that, dynamic memory allocation is very rewarding.

Using template classes that manage your memory for you is even more rewarding than doing it yourself.

Are things like long double or wchar_t used a lot?

I actually haven't found a single use for a double precision type yet in a game programming context. Based on that (games that is) I have to say they are pretty worthless IMO. Of course if that statement is questionable then please enlighten me. =P

We've decided to use SFML.

What did I miss? When was that decided? ..Oh well. Guess that takes care of that.


Well I did just get done messing around with SFML and at the time I didn't really feel like sharing my opinions about it, but I think I'll do that right now, so here it is in a nutshell:

Good - SFML is reasonably small and tidy, and the linking libs come in components, so you don't have to use the whole shebang. Plus modifying the source is pretty painless.
Bad - SFML takes encapsulation a little too seriously and hides some important data you NEED to access. (I need to at least =P) So we are 100% guaranteed to have to modify the source code in some small way. Also a full stable version is not out yet, so periodic updates could be required.
Good - Cross platform input, window, and joystick functions wrapped in an easy-to-use c++ API.
Bad - I found the graphics package to be really obtrusive. For example: To draw a triangle you have to create a polygon class, send via functions some data, then render it by using a Window instance. Here's another one: You need a RenderWindow class, a Sprite class, and an Image class to draw a sprite. Your Sprite needs an 'Image' handle and your RenderWindow needs a Sprite handle. You can't just draw a sprite from the Sprite itself, Only a RenderWindow( object ) call can draw stuff.
The way I view this is lots of unnecessary memory being wasted and lots of extra pointers being thrown everywhere. I don't see how you can get away from this the way it's designed. Also it doesn't support batching or delayed drawing so be expected to write some big functions with huge amounts of sf::object types as an integral part. The sfml::graphics api just doesn't seem suited for large projects IMHO.


Since most of the bad points, and none of the good ones, has to do with drawing, I therefore I propose the following: Using the easy to use c++ interface of the sfml::window library, sfml::main library, and the sfml::input library, and foregoing the use of the sfml::graphics library directly.


..Yeah I know, picky picky picky. In all honesty though it IS completely backwards. That much is certain.

Edited by Gleeok, 05 July 2010 - 02:28 AM.

[Joe123]

Are things like long double or wchar_t used a lot?

With the programming we do at uni we use precision types (indirectly), but programming for physics is a lot different to programming for games though.

What did I miss? When was that decided? ..Oh well. Guess that takes care of that.
Well I did just get done messing around with SFML and at the time I didn't really feel like sharing my opinions about it, but I think I'll do that right now, so here it is in a nutshell:

Good - SFML is reasonably small and tidy, and the linking libs come in components, so you don't have to use the whole shebang. Plus modifying the source is pretty painless.
Bad - SFML takes encapsulation a little too seriously and hides some important data you NEED to access. (I need to at least =P) So we are 100% guaranteed to have to modify the source code in some small way. Also a full stable version is not out yet, so periodic updates could be required.
Good - Cross platform input, window, and joystick functions wrapped in an easy-to-use c++ API.
Bad - I found the graphics package to be really obtrusive. For example: To draw a triangle you have to create a polygon class, send via functions some data, then render it by using a Window instance. Here's another one: You need a RenderWindow class, a Sprite class, and an Image class to draw a sprite. Your Sprite needs an 'Image' handle and your RenderWindow needs a Sprite handle. You can't just draw a sprite from the Sprite itself, Only a RenderWindow( object ) call can draw stuff.
The way I view this is lots of unnecessary memory being wasted and lots of extra pointers being thrown everywhere. I don't see how you can get away from this the way it's designed. Also it doesn't support batching or delayed drawing so be expected to write some big functions with huge amounts of sf::object types as an integral part. The sfml::graphics api just doesn't seem suited for large projects IMHO.
Since most of the bad points, and none of the good ones, has to do with drawing, I therefore I propose the following: Using the easy to use c++ interface of the sfml::window library, sfml::main library, and the sfml::input library, and foregoing the use of the sfml::graphics library directly.
..Yeah I know, picky picky picky. In all honesty though it IS completely backwards. That much is certain.

Encapsulation is something which should be taken seriously. If modifying the source is that simple though then it shouldn't be a problem surely?
I don't see why we shouldn't use different parts of things to satisfy our needs though.
Unless the other alternatives as equally as good/easy to use functions for window/input as sfml, in which case we might as well use those.

[Koopa]

There's a lot of examples of WxWidgets here.
Basically, you can do anything you can in a 'windows' application.

Here's one screenshot of a dialog editor using wx:


Now imagine the controls (buttons, menus etc. in the lower right-hand corner replaced by tiles, the dialog in the middle by a screen, the properties in the lower left hand show tile properties, the component tree on the top left becomes a list of maps whereas at the top right there's a minimap of the current map.
Menus and toolbars hold ZM-related items, scrollbars stay (and can be added around the main screen too).
We could have multiple windows if we want - or, as in the screenshot, tabs.
The panels round the side with a "pin" icon can be detached to become windows of their own and moved around the screen too.

That's one way the new editor could work.

[lucas92]

Just a quick update: SFML seems to be set up right, while I'm having problems building a universal binary for wxWidgets. I know this should be possible...probably just making a silly mistake. This shouldn't slow me down too much.

Yeah, I'm also having problems building a wx project with Code::Blocks...

[lonegraywolf]

I got wxWidgets installed on my end...at the expense of Mac OS X 10.4 (Tiger) users. Most of the Mac users should be upgraded by now to at least Leopard at this point anyway.

[Bourkification]

I got wxWidgets installed on my end...at the expense of Mac OS X 10.4 (Tiger) users. Most of the Mac users should be upgraded by now to at least Leopard at this point anyway.

Well the 2.5 builds only support Leopard and Intel based processors anyways, so it's not really that big of a deal.

[Beefster]

My major complaint about SFML is the over-reliance on the Window class. (and really, classes in general) While it does help with cleaning up code, it's just ridiculous needing a class to draw a triangle.

So Gleeok: do you think you could break through this nuiciance of SFML and enable us to directly draw primitives and such? Or even set things up to use SFML for everything except graphics.

[Gleeok]

Yeah, too many classes with dependencies to other classes. I think the Text class needs a Font class and a Render class too. BUT, I will say this again: Everything else about it is very nice and not bound by the same rules as the graphics class. Don't misunderstand, I think SFML is a great library to use. I also think the same with GLFW, SDL, and GLUT. Like I said back on page 4 or so of this thread, they all have their strong points and weak points depending on what it is you require from them. It's a toolbox.

Like I also said a ways back in this thread, I'd by glad to help at least with the rendering so as to simplify that aspect of it when or if this project gets off the ground. Of course I'm not forcing anyone to have to use OpenGL if no one wants it, however the alternatives are D3D (windows only) and soft rendering, so I would think this is a no-brainer. Be warned though if this ever gets somewhere and I am involved, then I insist that drawing be at least 10 times faster than game-maker.

[Koopa]

You forgot the 'Character' class

I think it might be a good idea to have the core game code library-independent where sensibly possible, so the core is just a bunch of numbers representing the game and methods for manipluating them (like movement, creating/destroying enemies etc.). The UI/graphics etc. code can then be called from the core but without beeing too entwined.

[Snarwin]

I think it might be a good idea to have the core game code library-independent where sensibly possible, so the core is just a bunch of numbers representing the game and methods for manipluating them (like movement, creating/destroying enemies etc.). The UI/graphics etc. code can then be called from the core but without beeing too entwined.

Quoted for support, and I'd also add that the less the "core" of the engine depends on a particular library, the more easy it'll be to port it to other platforms.

[Cameron]

So what are the remaining things we want to figure out? I mean features, gui layout, libraries, and things like that. We should have everything we want written down, maybe in that Google Docs from earlier. Right now we're kinda throwing ideas around and if we want this to get off the ground we should probably start making an official list.

EDIT: Or we could start up that forum and have an official thread there. This is starting to get disorganized what with 16 pages and 240 posts.

Edited by XxGamasterxX, 07 July 2010 - 05:24 PM.