411 replies to this topic

[Koopa]

In old times, all graphics were done by the processor itself which calculated the pixels to draw and how to colour them and drew them on the screen. Then, graphics cards came along. Nowadays the amount of RAM in your graphics gard is one of the key factors in how well games can run.

OpenGL is a free and open standard for using a graphics card. The idea is that a game only specifies objects like lines, circles and polygons in a mathematical way (can be 2D or 3D) and leaves it to the graphics card to actually draw them, that is calculate how to translate it into pixels.

This means that you can define an object like a bush as a mathematical object - circles and polygons, points and coordinates - and then just use commands broadly like "zoom out" or "rotate the camera" or "change the lighting".

OpenGL is multi-OS and supports all major graphics cards, but if what you have is a 16x16 sprite where the pixels are already calculated, it won't bring you so many benefits. To get the full use of OpenGL, you couldn't just draw a sprite sheet - you'd need a specialized editor where you made 'models' of your objects.

[Hoten]

I think I understand. I've been sort of babied in the graphical part of programming - thanks to AS3

So, we should just use, what, the default graphic functions of STD/SFML/whatever is decided upon?

[lucas92]

Well, SFML is hardware acceleration, and we get the benefits of its simplicity.

But if Gleeok has a better graphics engine made then we should use it.

[Gleeok]

@Koopa: I have to wholeheartedly disagree with you on all counts about the OpenGL issue. It's a shame since I was becoming rather fond of agreeing with you too. Ha! tsk.

OpenGL is a 3D graphics API, however 2D is trivial in that each vertex is automatically assigned a z value of 0 when none is specified. Also disabling depth testing/lighting/3d states is like putting in a rocket pack on your graphics card. It's FAST. Using up much of your precious CPU cycles on rendering while your graphics card watches in horror is like ..well like going to a homeless shelter and burning a suitcase full of money. ..Yeah, If you do that then you might go to hell. It's Bad, very bad. ..And why not let the GPU handle most of the Matrix transformations as well. It's what it's good at. This frees up valuable cycles for things like say.. a scripting engine that can handle thousands of object scripts running per frame. :-D

Even something like SFML using immediate mode, translations, and texture binding (which is slow) each call is waaay faster than say allegro's blitting routines. Imagine running zc (allegro) at 1920x1080 resolution, or Haha this is funny... imagine the Playstation 3 running allegro instead of *I think it's* OpenGL ES 2.0. lol.

Also your thinking of 'pixel coordinate' mode, or whatever. -Where the size of a sprite is set and you want it to be that size unless you specify differently? (I think that's what you meant) Doesn't matter. Rendering a 16x16 sprite to be 16x16 pixels is the same thing as mapping it to a 16.294 pixel radius sphere really. The difference is basically the projection matrix and viewport. I see where you are saying it is more complicated though; probably a texture atlas is what you are thinking of. The benefit to this though is that every graphic that shares a texture can be batched together and sent to the GFX card in very few calls. Sprite batching is ridiculously fast and any time spent sorting this data you get back three-fold.

There are a few downsides though. For instance managing palettes is really, really hard. It doesn't help that the glColorTable* EXT stuff is hardly supported..blah. Render to texture is lacking. And it's hard to learn if you have no experience with it..In fact chapter one in the red book should be titled: "101 things not to do, but you'll do them anyway...because it's states.".


..Anyway sorry for that. I could of just said "What? You so crazie.", but making those funny comparisons is just too much fun.


[edit]

Well, SFML is hardware acceleration, and we get the benefits of its simplicity.

Whoops, forgot about this. To be honest, I'm not up to date on what's being worked and developed regarding these libs. I've just been using pure Win32 API for whatever random thing I mess with for the last year or so. SDL, SFML, Allegro5, GLUT,or GLFW are what come to mind.
SDL is bulky and maybe getting dated(?) but it's been used so much and you know it works and easy to use. However if someone could explain why *_RESIZE always made the screen flicker and why the fullscreen settings would get corrupted and change your resolution on win32 then let me know.
GLFW is really lightweight which is nice, A5 is not done yet, GLUT is not maintained.
I've never used SFML; Although it looks to be fairly lightweight (always a plus), and it's image_add_on uses SOIL (what I use), libpng, jpeg, zlib already.

..so in summary. I have no clue really. whatever works, use it!

But if Gleeok has a better graphics engine made then we should use it.

I do. ..The plus side is that you won't have to use a single gl* command. The down side is now I have to fix a few bugs!

I got the day off today. Woohoo! And I actually started binding it to a C++ scripting api I just started working on. It uses AngelScript : http://www.angelcode...nual/index.html which is awesome. We'll see how it goes!!

Edited by Gleeok, 25 June 2010 - 03:10 PM.

[Koopa]

Those are all valid points, Gleeok. Seeing as you've used both OpenGL and (presumably) SDL, how much extra effort do you think it'd be for developers, in terms of learning time and during the actual programming?

Also, just to be sure, is OpenGL likely to run on as many platforms as plain SDL? I don't see why not, but just checking. What about a laptop with onboard graphics, for example?

I'm still not quite convinced of the benefits OPenGL would bring specifically in a ZC setting. What else than pixel-coordinate mode would we need there, and how often would we render a sprite to a sphere?
Won't 90% of the graphics consist of blitting prerendred sprites onto the screen? Quest makers or in particular tile makers at the moment can draw tiles like in an image editor and, palette issues notwithstanding, it's essentially fully rendered the moment you save in ZQuest. A 'rotating fireball' is not a model that's rotated with a matrix but a sequence of a few sprites that cycle.

Using OpenGL would definitely be like swapping an old car that can do 50mph at most for a brand-new flashy model that can do 200mph easily - but won't we be driving in a 30mph zone most of the time?

[Lemmy Koopa]

When is 2.50 going to be done?

[Cameron]

When is 2.50 going to be done?

No one knows. But, the way it appears to be going I'd say about... a long, long time.

[Yapollo]

When is 2.50 going to be done?

As Nathaniel pointed out, if we waited until every little bug is fixed, 2.5 will take forever to finish.

He argued that we should set a deadline, and get as much done as we can before the final version is set out.

On that note, when should we make the deadline.

[Nathaniel]

End of this year, I say. Around Christmas/Chanukah/New Years/other December holidays. Lots of people have time off then, and more people than usual will be paying attention. Also, 6 months should be ample time to fix a decent number of the remaining bugs, focusing mainly on the worst of the bugs that have been found and still exist. Decide which bugs are high priority to fix, which are medium priority, and which are low priority, or something similar to that.

[Lemmy Koopa]

Well as long as all necessary bugs are fixed I don't see why a full version shouldn't be done, though there's still a lot crash problems I get.

[Gleeok]

I made a scripting engine. X_X Might as well just post it in here.

CODE

int objectID = 0; //global variable

class MyTriforce
{
    void render(color c1, color c2, color c3, vector2 offset)
    {
        draw.triangle( offset + vector2(400, 100), offset + vector2(300,167), offset + vector2(500,167), c3, c2, c1 );
        draw.triangle( offset + vector2(300,167), offset + vector2(200,234), offset + vector2(400,234), c3, c2, c1 );
        draw.triangle( offset + vector2(500,167), offset + vector2(400,234), offset + vector2(600,234), c3, c2, c1 );
    }
}
    
class test : MyTriforce
{
    int ID;
    string str;
    vector2 p1;
    vector2 p2;
    vector2 p3;
    color col;

    test()
    {
        ID = ++objectID;
        Print("object " + this.ID + " constructor called \n");
    }

    ~test()
    {
        Print("object " + this.ID + " destructor called \n");
    }
    
    void run() //All objects that have a void run() method get called every frame...is what I've got for running them ..so far anyway...
    {
        p1 = vector2(0,    80);
        p2 = vector2(800,  80);
        p3 = vector2(400, 600);

        draw.triangle( p1, p2, p3, col.red(), col.green(), col.blue() );

        // call base::render.
        this.render( col.yellow(), col.red(), col.blue(), vector2(0,150) );
    }
}

Woot. Simple additive blending is why they overlap like that. Fun stuff. What do you guys think? How to make the language better? ..(Other than it being C and/or C++ syntax obviously).


@zc 2.5 getting done. Honestly I don't know; When it's done. At this point if all the critical bugs get fixed then I will personally Email the President and let him know that ZC 2.5 beta1 should be arriving. Mr President, Mr President: What are your comments on the 2.5 fiasco!? "Unfortunately the Navy Seals team we sent in to rescue the princess has not returned...We are now at DefCon 3."

@Koopa: There's always some give and take for anything. Blitting a sprite is the same regardless, minus a few exceptions. Animated Sprites: allegro: you might have 12 seperate bitmaps in an array(just an example), which is all heap data, then blit them one after another. OpenGL: All the frames of animations are stored on a texture with other sprite animations, which have been pre-loaded, and blitting them is finding the correct rectangle or uv coordinates. Not really that different, except that the first one is much slower. =P I don't think any multi-media library or engine has been made without hardware accelerated graphics in the last 5 years though. It's dying. I don't know...lets ask the people. ^_^

[lucas92]

The only thing I'm not too sure about is the objectID. Why would that variable be used for?

Otherwise, great work! I can help with scripting.

[Gleeok]

The only thing I'm not too sure about is the objectID. Why would that variable be used for?

Otherwise, great work! I can help with scripting.

Oh, sorry. Those parts are just for my own testing purposes. You don't even need ctors at all.

It has the entire cmath functions and an array class now. ...I need to add multi-dimensional arrays though...

I've goofing around with it's speed capabilities, and it seems like it's faster than what I thought:

CODE

int test_math_speed()
{
    int j;
    float k = 12.45f;
    for(int i = 1; i < 10000; ++i)
    {
        //j = i + i - i; //  really fast
        //j = i * i / i;  // really fast

        // test func calls
        //k = math.atan2(k, 32.67f); // suprisingly fast.
        call_dummy_cpp_func(); // script to cpp incurs very little overhead.
    }
    return j;
}

To quote Ricky Bobby; "I wanna go fast." Seems like the only bottleneck I've come upon might be cpp side in before the scripts are executed.. hmm.. I think I can fix that. .Other than that it's pretty fast! ..Judjing from other comparisons it doesn't seem to be as fast as Lua though. (Probably not an easy feat to get to Lua or C# speed.)

[lucas92]

If it's faster than allegro with c++, it's all good.

Edited by lucas92, 26 June 2010 - 04:54 PM.

[lonegraywolf]

I may have C++ skills, but I haven't used them with SDL/OpenGL yet. If it helps, I'm a Mac user as well, so I can definitely help with beta testing and compiling here. I just don't know how much coding I can contribute.

If anyone in here wants to learn some coding basics, however...I can probably give some lessons on Skype for C++ and python.

One other thing: look into git or hg/mercurial for source control. Making branches is easier in my opinion with those two since it doesn't require copying the entire source code. Also, you aren't forced to have an internet connection either: that is only for when you push and pull from central repositories.