February 26, 2015
On Thursday, 26 February 2015 at 08:03:59 UTC, Gan wrote:
> On Thursday, 26 February 2015 at 06:33:26 UTC, Gan wrote:
>> On Thursday, 26 February 2015 at 06:32:07 UTC, Gan wrote:
>>> On Thursday, 26 February 2015 at 03:17:32 UTC, stewarth wrote:
>>>> On Thursday, 26 February 2015 at 03:01:42 UTC, Rikki Cattermole wrote:
>>>>> On 26/02/2015 3:57 p.m., Gan wrote:
>>>>>> On Thursday, 26 February 2015 at 02:32:51 UTC, stewarth wrote:
>>>>>>>
>>>>>>>
>>>>>>> I'd also try hacking in Window.d directly to see if even basic gl
>>>>>>> commands work, e.g. immediately after window and context creation, try
>>>>>>> rendering a triangle then tweak the context initialisation to see if
>>>>>>> it affects anything.
>>>>>>>
>>>>>>> It may help you track down exactly which part of the GL setup is
>>>>>>> causing problems.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Stew
>>>>>>
>>>>>> I know almost nothing about OpenGL but using your method(sorta):
>>>>>> void reportGLErrors() {
>>>>>> GLenum errCode;
>>>>>> const GLubyte *errString;
>>>>>> if ((errCode = glGetError()) != GL_NO_ERROR)
>>>>>> {
>>>>>>     writeln("OPEN GL ERROR: ", errCode);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> I get error code 1282 repeatedly.
>>>>>>
>>>>>> From a google search someone says:
>>>>>> "First, glGetError() will return 1282 - invalid operation if the GL
>>>>>> context is not current (or not yet created). So, create your context
>>>>>> first, then call glGetError. And, verify that any parent class or member
>>>>>> class does not call GL functions in their constructors or prior to
>>>>>> context being created."
>>>>>>
>>>>>> Can someone with more OpenGL knowledge clarify what this means?
>>>>>
>>>>> 1. Program starts
>>>>> 2. Window gets created
>>>>> 3. Context gets created
>>>>> 4. Context is activated
>>>>> 5. Profit???
>>>>>
>>>>> Basically before the context is created and activated you cannot call any OpenGL functions. If you do, they will error out.
>>>>>
>>>>> The bit about constructors ext. don't worry about it. Its just about e.g. where the calls to OpenGL can exist.
>>>>
>>>> Yes, my bad sorry, but whatever works. The point is dive in and start printfing about in Window.d, checking error codes to try and figure out where things become stuffed up.
>>>>
>>>>
>>>> Cheers,
>>>> Stew
>>>
>>> I did what you suggested. I added a bunch of writeln and reportGLErrors. These are the results:
>>> glMatrixMode(GL_PROJECTION);
>>> OPEN GL ERROR: 1282
>>>
>>>
>>>
>>> glLoadIdentity();
>>> OPEN GL ERROR: 1282
>>>
>>>
>>>
>>> glShadeModel(GL_FLAT);
>>> OPEN GL ERROR: 1282
>>>
>>>
>>> glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_FASTEST);
>>> OPEN GL ERROR: 1280
>>>
>>>
>>> glHint(GL_GENERATE_MIPMAP_HINT, GL_FASTEST);
>>> OPEN GL ERROR: 1280
>>>
>>>
>>> glOrtho(0, vMode.width, vMode.height, 0, 1, -1);
>>> OPEN GL ERROR: 1282
>>>
>>>
>>> Each error happens after each line is called. I'm not sure why this happens or what it means.
>>
>> According to docs: 1280 is GL_INVALID_ENUM
>
> Figured it out. DGame wants OpenGL 3.0+ context. However it uses some functions in OpenGL 2.1 that have been depreciated. The mac OpenGL doesn't allow depreciated functions.
>
> DGame's OpenGL code is too outdated to run on a 3.0+ GL context on mac.
>
> Required fix: Either lower the context to 2.1 or upgrade the code to not use depreciated functions.

Great job, well done :)

It's never easy debugging those sorts of errors.

/stew



February 26, 2015
I've just pushed the current state of the 0.5.0 version:
https://github.com/Dgame/Dgame/tree/0.5.0

It's far from finished but it works. So if anyone has requests, wishes or suggestions: now is the time. :)
February 26, 2015
On Thursday, 26 February 2015 at 20:43:20 UTC, Namespace wrote:
> I've just pushed the current state of the 0.5.0 version:
> https://github.com/Dgame/Dgame/tree/0.5.0
>
> It's far from finished but it works. So if anyone has requests, wishes or suggestions: now is the time. :)

That's great :)


At the moment my small test apps don't build due to missing features such as Audio, System.Clock etc. I assume these will be added as work progresses?

I'll do some testing over the weekend with what's in place on the 0.5.0 branch and submit bug reports if I find anything.

Cheers,
Stew




February 26, 2015
On Thursday, 26 February 2015 at 22:09:33 UTC, stewarth wrote:
> On Thursday, 26 February 2015 at 20:43:20 UTC, Namespace wrote:
>> I've just pushed the current state of the 0.5.0 version:
>> https://github.com/Dgame/Dgame/tree/0.5.0
>>
>> It's far from finished but it works. So if anyone has requests, wishes or suggestions: now is the time. :)
>
> That's great :)
>
>
> At the moment my small test apps don't build due to missing features such as Audio, System.Clock etc. I assume these will be added as work progresses?


No, only the tests in test/main.d are working currently.
But it's possible, that Dgame 0.5.0 will break some things.
E.g. The static make methods in Shape and Surface were converted into CTor calls and I guess that I will abandon Image and TileMap.

Next step is Font, Text and Spritesheet. Then I'll inspect Clock, Power and MessageBox and in the end I'll inspect Audio. I think the most breaking changes will happen here, because I'll use this time SDL_Audio instead of OpenAL.

> I'll do some testing over the weekend with what's in place on the 0.5.0 branch and submit bug reports if I find anything.
>
> Cheers,
> Stew

Thanks, that would be great!
February 27, 2015
On Thursday, 26 February 2015 at 22:27:12 UTC, Namespace wrote:
> On Thursday, 26 February 2015 at 22:09:33 UTC, stewarth wrote:
>> On Thursday, 26 February 2015 at 20:43:20 UTC, Namespace wrote:
>>> I've just pushed the current state of the 0.5.0 version:
>>> https://github.com/Dgame/Dgame/tree/0.5.0
>>>
>>> It's far from finished but it works. So if anyone has requests, wishes or suggestions: now is the time. :)
>>
>> That's great :)
>>
>>
>> At the moment my small test apps don't build due to missing features such as Audio, System.Clock etc. I assume these will be added as work progresses?
>
>
> No, only the tests in test/main.d are working currently.
> But it's possible, that Dgame 0.5.0 will break some things.
> E.g. The static make methods in Shape and Surface were converted into CTor calls and I guess that I will abandon Image and TileMap.
>
> Next step is Font, Text and Spritesheet. Then I'll inspect Clock, Power and MessageBox and in the end I'll inspect Audio. I think the most breaking changes will happen here, because I'll use this time SDL_Audio instead of OpenAL.
>
>> I'll do some testing over the weekend with what's in place on the 0.5.0 branch and submit bug reports if I find anything.
>>
>> Cheers,
>> Stew
>
> Thanks, that would be great!

Hey, I'm using tilemap :P

I guess a separate project for tilemaps built on Dgame would be cool. I might look into this during the semester break.

One thing that would be cool is some sort of support for 2D physics. It's probably outside Dgame scope but as a separate project that keeps a consistent API with Dgame would be nice. Kind of like the way SDL, SDL_image, SDL_ttf all do.

Cool, two new projects for me to look into when I should be studying :)


Thanks,
amber

February 27, 2015
On Thursday, 26 February 2015 at 02:22:18 UTC, stewarth wrote:
> On Wednesday, 25 February 2015 at 15:36:21 UTC, Gan wrote:
>> On Tuesday, 24 February 2015 at 22:03:29 UTC, stewarth wrote:
>>> On Tuesday, 24 February 2015 at 21:10:53 UTC, Gan wrote:
>>>> On Tuesday, 24 February 2015 at 21:07:04 UTC, stewarth wrote:
>>>>> On Tuesday, 24 February 2015 at 19:32:08 UTC, Gan wrote:
>>>>>> On Tuesday, 24 February 2015 at 16:28:59 UTC, Namespace wrote:
>>>>>>>> I had to force dub to upgrade in order for it to pull the latest code from the master branch.
>>>>>>>>
>>>>>>>> But on the plus side it runs.
>>>>>>>>
>>>>>>>> On the downside it still only displays a blank white screen for Mac users.
>>>>>>>
>>>>>>> As growlercab pointed out (https://github.com/Dgame/Dgame/pull/29), I think also that you should set the Version to 3.2 rather than 3.0. Could you give it a try and say if that works for you?
>>>>>>
>>>>>> No dice. Running the shapes tutorial again, just a blank screen. Console output looks good though:
>>>>>> init openAL
>>>>>> Derelict loaded GL version: GL33 (GL33), available GL version: 3.3 INTEL-10.0.22
>>>>>> Quit Event
>>>>>> Finalize Sound (0)
>>>>>> >> Sound Finalized
>>>>>> Text: Finalize Font
>>>>>> Font finalized
>>>>>> Close open Windows.
>>>>>> Open Windows closed.
>>>>>> Finalize Texture (0)
>>>>>> >> Texture Finalized
>>>>>> quit sdl
>>>>>
>>>>> Did you try commenting out the line that sets the forward compatibility flag as well?
>>>>> (sorry it isn't clear from the posts)
>>>>>
>>>>> if (style & Style.OpenGL) {
>>>>> SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
>>>>> SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3);
>>>>> SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);
>>>>> /*
>>>>> * SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS,
>>>>> *           SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG);
>>>>> */
>>>>> }
>>>>>
>>>>> This fixed a similar issue for me on Linux.
>>>>>
>>>>> Cheers,
>>>>> stew
>>>>
>>>> Yeah I did that, doesn't show anything but a blank white screen.
>>>
>>> OK, thanks for letting me know.
>>
>> Is there anything more I can test to try to get it working on Mac?
>>
>> Also anyone else have a Mac to test on? I wanna make sure it's not just me getting the blank white screen.
>
> Without a MAC I am just guessing, but my next steps would be along the lines of:
>
> 1. The venerable printf binary search bug hunt approach :)
>
> Check glGetError, which you can turn the error into a string with GLU as follows:
>
> ---
> void reportGLErrors() {
>     GLenum errCode;
>     const GLubyte *errString;
>     if ((errCode = glGetError()) != GL_NO_ERROR)
>     {
>         errString = gluErrorString(errCode);
>         writeln(errString.fromStringz)
>     }
> // UNTESTED!!
> }
> ---

This module should work as a standalone with a few tiny import changes: https://github.com/Dav1dde/glamour/blob/master/glamour/util.d

The interesting bit is checkgl, used for example like this:

checkgl!glDrawArrays(GL_POINTS, 0, 10);

then you get a nice debug message if glDrawArrays reports an error. It will also report if a previous error has occurred and wasn't cleared, but of course in that case it won't be able to tell you where.

I wrap every OpenGL call with checkgl, it helps immensely.
February 27, 2015
> Hey, I'm using tilemap :P
>
> I guess a separate project for tilemaps built on Dgame would be cool. I might look into this during the semester break.

It's very easy to build a TileMap if you use Sprites. So I don't see (currently) any use case of the TileMap module.

> One thing that would be cool is some sort of support for 2D physics. It's probably outside Dgame scope but as a separate project that keeps a consistent API with Dgame would be nice. Kind of like the way SDL, SDL_image, SDL_ttf all do.

Yeah, that would be nice and usefull for future games. :)

> Cool, two new projects for me to look into when I should be studying :)
>
>
> Thanks,
> amber

February 27, 2015
> This module should work as a standalone with a few tiny import changes: https://github.com/Dav1dde/glamour/blob/master/glamour/util.d
>
> The interesting bit is checkgl, used for example like this:
>
> checkgl!glDrawArrays(GL_POINTS, 0, 10);
>
> then you get a nice debug message if glDrawArrays reports an error. It will also report if a previous error has occurred and wasn't cleared, but of course in that case it won't be able to tell you where.
>
> I wrap every OpenGL call with checkgl, it helps immensely.

Yes, I will do so in the future too.
February 28, 2015
> Next step is Font, Text and Spritesheet. Then I'll inspect Clock, Power and MessageBox and in the end I'll inspect Audio. I think the most breaking changes will happen here, because I'll use this time SDL_Audio instead of OpenAL.

Font, Text, Clock (renamed to StopWatch) and Power (renamed to Battery) were also ported. The Audio package also. Spritesheet should be redundant now, because Sprite has now a clipRect, to support the Spritesheet behaviour.

What is left: add missing comments / complete comments and renew the documentation. After that I will update the website.

We are moving forward! :)
February 28, 2015
On Saturday, 28 February 2015 at 11:02:31 UTC, Namespace wrote:
>> Next step is Font, Text and Spritesheet. Then I'll inspect Clock, Power and MessageBox and in the end I'll inspect Audio. I think the most breaking changes will happen here, because I'll use this time SDL_Audio instead of OpenAL.
>
> Font, Text, Clock (renamed to StopWatch) and Power (renamed to Battery) were also ported. The Audio package also. Spritesheet should be redundant now, because Sprite has now a clipRect, to support the Spritesheet behaviour.
>
> What is left: add missing comments / complete comments and renew the documentation. After that I will update the website.
>
> We are moving forward! :)

This is exciting. I'll test my space background in DGame to compare performance to SFML. If it's favorable, I'm immediately switching.