FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

my slight mods to derelict...

 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
clayasaurus



Joined: 21 May 2004
Posts: 857
PostPosted: Wed Oct 20, 2004 9:38 am    Post subject: my slight mods to derelict... Reply with quote
Hey all. I've recently started converting the tutorials over at gametutorials.com to D using derelict in hope that they may include it on their site : )

anyway... besides the little linux things, do you care if i change

#1)
Code:

import derelict.glu.glu;

to
Code:

import derelict.opengl.glu;


#2)

Code:

struct SDL_VideoInfo
{
   Uint32 flags;
   Uint32 video_mem;
   SDL_PixelFormat *vfmt;
}


to

Code:

struct SDL_VideoInfo
{
  Uint32 hw_available;
  Uint32 wm_available;
  Uint32 blit_hw;
  Uint32 blit_hw_CC;
  Uint32 blit_hw_A;
  Uint32 blit_sw;
  Uint32 blit_sw_CC;
  Uint32 blit_sw_A;
  Uint32 blit_fill;
  Uint32 video_mem;
  SDL_PixelFormat *vfmt;   
}

as described here --> http://sdldoc.csn.ul.ie/sdlvideoinfo.php

I don't want to pollute derelict so i'm asking here first. #1 i could easily just change to derelict.glu.glu if you want. but the reason why i lean towards the other way is that i think all opengl files should go under the same directory... like

Code:

#include <GL/gl.h>
#inclulde<GL/glu.h> // on linux at least, glu is in the same gl directory, along with any other gl files


just makes more sense to me.

#2, is there a way to do these same tests using flags?

Code:

SDL_VideoInfo * VideoInfo = SDL_GetVideoInfo();

if(VideoInfo . hw_available)
   VideoFlags |= SDL_HWSURFACE;

if(VideoInfo . blit_hw)
   VideoFlags |= SDL_HWACCEL;


if they arn't in the struct? do i just use something like

Code:

if (VideoInfo.flags & SDL_HWSURFACE)
   VideoFlags |= SDL_HWSURFACE;


or would i just use

Code:

VideoFlags = VideoInfo.flags;
Back to top
View user's profile Send private message AIM Address
JJR



Joined: 22 Feb 2004
Posts: 1104
PostPosted: Thu Oct 21, 2004 12:07 am    Post subject: Re: my slight mods to derelict... Reply with quote
clayasaurus wrote:
Hey all. I've recently started converting the tutorials over at gametutorials.com to D using derelict in hope that they may include it on their site : )


Great! I've never seen the gametutorials.com site before. They have a lot of good information over there. I had planned to do something similar with the nehe site tutorials, but I guess somebody else beat me to it: they have sdl/opengl D versions of these tutorials up now (well, for the earlier lessons anyway). I'm still working on some conversions anyway, but using glfw instead of SDL and combining D OOP techniques over procedural. It's actually turning out to be a pretty fun way to learn opengl and d programming techniques.
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
PostPosted: Thu Oct 21, 2004 1:21 am    Post subject: Re: my slight mods to derelict... Reply with quote
clayasaurus wrote:
Hey all. I've recently started converting the tutorials over at gametutorials.com to D using derelict in hope that they may include it on their site : )


That's great! But, before you submit anything, I would ask you to wait. Anyone who finds your ports at GameTutorials would expect to download Derelict and everything will work out of the box. But I still need to get the linux fixes in, and I'm replacing glee with glew.

Quote:

anyway... besides the little linux things, do you care if i change

#1)
Code:

import derelict.glu.glu;

to
Code:

import derelict.opengl.glu;


I don't want to pollute derelict so i'm asking here first. #1 i could easily just change to derelict.glu.glu if you want. but the reason why i lean towards the other way is that i think all opengl files should go under the same directory... like

Code:

#include <GL/gl.h>
#inclulde<GL/glu.h> // on linux at least, glu is in the same gl directory, along with any other gl files


just makes more sense to me.


I'd ask that you not change this just yet. I need to consider if I want to move glu into the opengl package in the trunk. I can see arguments for and against, but the final decision will also affect how I package up glew. My thinking is that by keeping them separate it is easier to use DerelictGLU or DerelictGLEW with another Opengl binding, for example. Plus, not everyone wants to use glu or glew.

The reason I say this is that, if you look at the SDL makefile, there are several options to build with or without SDL_Image and SDL_Audio. But what if someone wants to use Derelict's SDL_Audio binding with an existing SDL binding outside of Derelict? Should I add makefile options to build SDL_Audio and SDL_Image bindings individually? I'll leaning toward moving this all out into separate libraries.

Now, with all of that said, it seems at first glance that there's no reason why I can't still keep DerelictGLU separate from DerelictGL and just rename the glu package to opengl.

Quote:

#2)

Code:

struct SDL_VideoInfo
{
   Uint32 flags;
   Uint32 video_mem;
   SDL_PixelFormat *vfmt;
}


to

Code:

struct SDL_VideoInfo
{
  Uint32 hw_available;
  Uint32 wm_available;
  Uint32 blit_hw;
  Uint32 blit_hw_CC;
  Uint32 blit_hw_A;
  Uint32 blit_sw;
  Uint32 blit_sw_CC;
  Uint32 blit_sw_A;
  Uint32 blit_fill;
  Uint32 video_mem;
  SDL_PixelFormat *vfmt;   
}

as described here --> http://sdldoc.csn.ul.ie/sdlvideoinfo.php


Take a closer look at how the struct is declared on that page. The first 8 flags are not individual Uint32 values. They are all part of a single Uint32 bitfield. Unfortunately, it's not possible to do the same thing in D. If you were to declare the struct as you have it, then there would be memory corruption between the D side and the SDL dll.

You did, however, lead me to realize an error. The blit_fill member is not part of the bitfield, and should be declared. So the D struct should look like this:

Code:

struct SDL_VideoInfo
{
   Uint32 flags;
        Uint32 blit_fill;
   Uint32 video_mem;
   SDL_PixelFormat *vfmt;
}


Quote:

#2, is there a way to do these same tests using flags?

Code:

SDL_VideoInfo * VideoInfo = SDL_GetVideoInfo();

if(VideoInfo . hw_available)
   VideoFlags |= SDL_HWSURFACE;

if(VideoInfo . blit_hw)
   VideoFlags |= SDL_HWACCEL;


if they arn't in the struct? do i just use something like

Code:

if (VideoInfo.flags & SDL_HWSURFACE)
   VideoFlags |= SDL_HWSURFACE;


or would i just use

Code:

VideoFlags = VideoInfo.flags;


Actually, none of the above. Those particular flags have nothing to do with the SDL_PixelFormat structure. What's happening here is that all of the values from the blit_hw member down to the blit_sw_A member (inclusive) are being packed into a single Uint32. So each value is either on or off. But this raises two problems.

First, as I said above, D does not support this (or at least it didn't at the time I ported this part - now I don't know as I'm out of touch with the latest changes/fixes, but I doubt it's been implemented). The obvious solution here is to define a custom set of flags for blit_hw, blit_hw_CC, blit_hw_A, etc... But then the question arises, what values to give each flag? C compilers are not required to implement bitfields in any particular order. That means that in this case blit_hw could be the least signficant bit, or the most significant (theoretically it could even be in the middle, but I doubt any compiler would do that). So any values I define could break if the SDL shared lib was compiled with a compiler that uses opposite/different ordering for the bitfields.

So for now, this is broken. The flags field only exists to keep struct memory alignment in sync between D and C. I had meant to document this, but I must not have. I thought I had at least commented it in the source. Anyway, I'll get on it.

I'll try to accelerate my work on the 0.2 release, and get it out the door as soon as I can. If you can hold off on submitting anything to gametutorials until that's done, I'd appreciate it.
Back to top
View user's profile Send private message Send e-mail
clayasaurus



Joined: 21 May 2004
Posts: 857
PostPosted: Thu Oct 21, 2004 10:27 am    Post subject: Re: my slight mods to derelict... Reply with quote
aldacron wrote:


I'll try to accelerate my work on the 0.2 release, and get it out the door as soon as I can. If you can hold off on submitting anything to gametutorials until that's done, I'd appreciate it.



Ok. There's around 50 tut's and I won't formally submit everything until they are all done. So there's some time yet. However I'll make sure they'll use .2 when it's all done.

So i take it I should just not use the video info blit_hw and those flags?
I guess I could do that.

I've never seen a unified bitfield like that. strange you can't do the same thing in D, I think i'll ask about that in the newsgroup and see what they have to say about it.

Last edited by clayasaurus on Thu Oct 21, 2004 2:31 pm; edited 1 time in total
Back to top
View user's profile Send private message AIM Address
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
PostPosted: Thu Oct 21, 2004 12:55 pm    Post subject: Re: my slight mods to derelict... Reply with quote
clayasaurus wrote:

I've never seen a unified bitfield like that. strange you can't do the same thing in D, I think i'll ask about that in the newsgroup and see what they have to say about it.


Both I and Sjoerd proposed possible solutions on the NG. If you define the struct as you already have, you can set the flags by OR'ing values to the variable.

E.g.:

flags = 0x001 | 0x002 | 0x004;

You could also make them constants.
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857
PostPosted: Thu Oct 21, 2004 2:44 pm    Post subject: Reply with quote
so what do you think aldacron? do you think any of these solutions will be sufficient for derelict?

in case you don't have time to read the newsgroup the other suggested solution from Sjoerd was

Code:

struct SDL_VideoInfo {
    const static uint hw_available = 0;
    const static uint wm_available = 1;
    const static uint blit_hw = 2;
    const static uint blit_hw_CC = 3;
    const static uint blit_hw_A = 4;
    const static uint blit_sw = 5;
    const static uint blit_sw_CC = 6;
    const static uint blit_sw_A = 7;

    bit[8] flags;
    ulong blit_fill;
    ulong video_mem;
    SDL_PixelFormat *vfmt;
}


personally this one is the only one i understand. i get confused by hex Embarassed

also, i assume this would allow you to query

Code:

   if(VideoInfo . blit_hw) // is hardware blitting available
      VideoFlags |= SDL_HWACCEL;
Back to top
View user's profile Send private message AIM Address
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
PostPosted: Thu Oct 21, 2004 10:15 pm    Post subject: Reply with quote
I've already posted here and (just now) on the NG why this is not a workable solution. From above:

aldacron wrote:

The obvious solution here is to define a custom set of flags for blit_hw, blit_hw_CC, blit_hw_A, etc... But then the question arises, what values to give each flag? C compilers are not required to implement bitfields in any particular order. That means that in this case blit_hw could be the least signficant bit, or the most significant (theoretically it could even be in the middle, but I doubt any compiler would do that). So any values I define could break if the SDL shared lib was compiled with a compiler that uses opposite/different ordering for the bitfields.


The very first thing I thought of was having something like BLIT_HW_CC = 0x000001 and so on, as you guys suggest. But I didn't know if the ordering of the bitfield would change from little-endian to big-endian systems. Then I realized I didn't know exactly what the ordering would be in the first place. A little research turned up that it is unspecified by the C standard. So if we implement this, you could test for blit_hw_CC, and it may work well on your system with your version of SDL, then break out in the wild because it's actually getting the result for blit_sw_A or something else (because SDL was compiled with a different compiler).
Back to top
View user's profile Send private message Send e-mail
JJR



Joined: 22 Feb 2004
Posts: 1104
PostPosted: Fri Oct 22, 2004 4:08 am    Post subject: Reply with quote
So what I'm getting here is that there really is no workable solution? In this particular instance, the C code in SDL might actually be considered bad design. The library becomes useful only if compiled in source form for each C compiler. It appears that interfacing with other languages was not a consideration here. Perhaps the SDL maintainers would be interested in knowing about this? I never realized how much trouble the C bit fields could become. I kind of see now why Walter decided not to include these in the D language specification (the D way using bit arrays seems more useful anyway, although I realize that it has no bearing on fixing this situation).
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
PostPosted: Fri Oct 22, 2004 5:02 am    Post subject: Reply with quote
aldacron wrote:
The very first thing I thought of was having something like BLIT_HW_CC = 0x000001 and so on, as you guys suggest. But I didn't know if the ordering of the bitfield would change from little-endian to big-endian systems. Then I realized I didn't know exactly what the ordering would be in the first place. A little research turned up that it is unspecified by the C standard. So if we implement this, you could test for blit_hw_CC, and it may work well on your system with your version of SDL, then break out in the wild because it's actually getting the result for blit_sw_A or something else (because SDL was compiled with a different compiler).


Although it would be a complicated solution, it might be possible to use a configure check to find out the correct ordering. A likely pitfall is that the compiler used to compile SDL must be known and present.
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
PostPosted: Sat Oct 23, 2004 8:46 pm    Post subject: Reply with quote
I'm sure that some sort of solution will present itself eventually. I have no idea what or when. One thing to do is to look at other SDL bindings and see how they handled it. Could also post on the SDL mailing list for suggestions.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group