Archived

This topic is now archived and is closed to further replies.

ZealousElixir

Fullscreen Catch-22

Recommended Posts

Hey, thanks for the read. I''m developing an API-independent rendering system for use in my upcoming game. I have the bare essentials up and running, i.e. I can create a window with either a D3D8 or OpenGL renderer and clear the background color. Past that, there isn''t much. The issue arises with the difference in how the APIs handle fullscreening. Direct3D simply asks for the fullscreen property as a parameter and takes care of everything else. OpenGL has no internal mechanism for going into fullscreen mode, and most people use ChangeDisplaySettings (on Win32) for that. However, my window and renderer classes are separate and have no knowledge of each other. I need a way to allow me to initialize my renderer as either fullscreen or windowed, with no other changes. That is, I don''t want to duplicate code (if the window class takes a fullscreen parameter, it has to know what type the renderer is; if the renderer is the one handling the fullscreen-ness, the OpenGL class would need volumes of data on how to destroy and recreate the window). I sense that I could fix it with an additional layer of abstraction, which will probably happen soon enough anyway, but it bothers me that I can''t unify the process any further (i.e. ONE place and only one where the fullscreen parameter exists and has an effect.) Thoughts? Peace, ZE. //email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

Share this post


Link to post
Share on other sites
quote:
Original post by Zorak
SDL


Amen, brother.

SDL is based on DirectX when running in Windows, so that solves your abstraction layer problem. I don''t know what it runs on in Linux. I imagine it runs directly on top of X.

Share this post


Link to post
Share on other sites
That might be an option if I was interested in not-for-profit development. However, this project might go commercial (and I can''t exactly distro source if that''s the case), and the question here is a matter of code, not of simply switching to a pre-made library.

Share this post


Link to post
Share on other sites
quote:
Original post by ZealousElixir
if the renderer is the one handling the fullscreen-ness, the OpenGL class would need volumes of data on how to destroy and recreate the window

you don''t need to destroy window to switch to fullscreen or back. you only need to take care of window sizing and styles. [i think; it''s been a while since i played with gl. maybe you don''t need to do anything to your window at all.]

Share this post


Link to post
Share on other sites
sdl is LGPL which means u can use it in a commericial app (without releasing your source code) there are no restrictions.
what u cant do with LGPL is change the sdl library.
many commerical games have used sdl eg UT (linux)

Share this post


Link to post
Share on other sites
got this from the sdl website

Q:
Can I use SDL in a commercial application?

A:
The simple answer is "Yes", just dynamically link with SDL and you''re fine.

Full details are available at: http://www.libsdl.org/license.php

Share this post


Link to post
Share on other sites
Also from that exact page:

You must also do one of the following:

1. Include the source code for the version of SDL that you link with, as well as the full source or object code to your application so that the user can relink your application,
or
2. Include a written offer, valid for at least three years, to provide the materials listed in option 1, charging no more than the cost of providing this distribution,
or
3. Make the materials listed in option 1 available from the same place that your application is available.


No thanks,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Let me explain the license in a way that almost everyone can understand.

Step 1: Dynamically link to SDL, release your game and the sourcecode to SDL, not the sourcecode of your game.
Step 2: ???
Step 3: Profit!

It''s really that simple, all you need to do is dynamically link and release the source code for SDL along with your game.

Share this post


Link to post
Share on other sites
If you read the SDL site, im quite positive that it somewhere is written that you can infact talk to the people in charge if you have any suggestions/questions/ideas or problems with the license.

Another way would ofcourse be to download the sources and look how they do it :D.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Step 1: Dynamically link to SDL, release your game and the sourcecode to SDL, not the sourcecode of your game.
Step 2: ???
Step 3: Profit!

emphasis added

Are you dense? It CLEARLY says, in a way most everyone can understand, "Include ... the full source or object code to your application so that the user can relink your application." Granted, this means I could just include the obj files from the compiler, but that still allows the user to view the assembly of the game, and that is NOT an option.

That''s all on SDL. If you have other comments on SDL, e-mail me privately, but I won''t be considering it as option. If you have something to add that relates to code, feel free to respond; otherwise this thread takes the axe.

Later,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

Share this post


Link to post
Share on other sites
yes that page is very unclear, + really should be rewritten.
esp
>>Include ... the full source or object code to your application so that the user can relink your application<<

but i know for a fact they mean the source code of SDL and NOT the code from your application that uses sdl.

the following piece on the page is a bit clearer.

>>The most common way to comply with the license is to dynamically link with SDL, and then include the SDL source code and appropriate notices with your application.<<

if u have any doubts post on the sdl mailing list + they will set u straight there

btw fuckin lawyer talk why cant they use plain english


http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Share this post


Link to post
Share on other sites
quote:
Original post by ZealousElixir
Are you dense? It CLEARLY says, in a way most everyone can understand, "Include ... the full source or object code to your application so that the user can relink your application." Granted, this means I could just include the obj files from the compiler, but that still allows the user to view the assembly of the game, and that is NOT an option.



That only means you have to realease the source code to the SDL portion of your app, not the entire source code. That means you''d only have to make sure all SDL code was encapsulated in a window manager class.

Share this post


Link to post
Share on other sites
If you read the latest LGPL license you''ll notice (under section 6) that you only have to include the source/object code to your application when you''re linking statically to the library. If you''re linking dynamically you do not have to include the source/object code to your app, but you still have to make available the source code to SDL itself.

Share this post


Link to post
Share on other sites
By the way, sorry for adding to the offtopic discussion. Back on topic now: Couldn''t you switch video modes using ChangeDisplaySettings regardless of the API you''re using and draw to a window the size of the screen like you do for OpenGL?

Share this post


Link to post
Share on other sites
Ok, look people. The above just means that you need to make sure the SDL code is there in case the user wants to recompile the libraries.

In other words, they need the source to SDL so they can recompile SDL. This is why you link to it dynamically, so they can use the new dll that they compile.

The source for SDL is up on http://www.libsdl.org so you really only have to tell the version of the dll you are using, and provide a link to the site.

Share this post


Link to post
Share on other sites
As to your problem, your window code should create the appropriate window for your needs. Your renderer code should initialize the API and whatnot, on OpenGL this means changing the res for fullscreen mode. The way I handle this for a fullscreen window is to create the window at 0,0 with the topmost and popup styles, then switch the res. As such, the window code does the window work, your OpenGL class just needs to know how to change the res and whatnot. This does however mean that after you init OpenGL you will have to make calls to your window code to give the window focus and show the window and whatnot if need be. If you did that regardless of which renderer is in use it wouldn''t hurt, DX does the same under the hood.

------------
- outRider -

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by ZealousElixir
Are you dense? It CLEARLY says, in a way most everyone can understand, "Include ... the full source or object code to your application so that the user can relink your application." Granted, this means I could just include the obj files from the compiler, but that still allows the user to view the assembly of the game, and that is NOT an option.



All the "object code" you need to include upon dynamically linking (as in using SDL as a DLL) would be your bloody EXE file. It is all that is required to link to e.g. a newer version of the library. In that case, simply by replacing the DLL.

Clear now?

Share this post


Link to post
Share on other sites
Could you give a little more detail on how its built(i dont need source, just pseudo, and im not gonna steal it either)?

And to the SDL''ers, STFU, this is NOT an SDL discussion thread, so f*cking cut it.

Share this post


Link to post
Share on other sites
Just wondering, whats your order of inheritance? Can I have a listing of your classes and their hierarchy that used in your renderer so I can make some suggestions? And I think that there is an old article here on gamedev about this very topic but im not sure, dont have time to search since im leaving for school right now.

[EDIT]
one suggestion that a friend of mine came up with would be to have your render have a default setting (for D3D, or GL) and keep track of which one is enabled. If the user changes this then destroy the renderer and create the other. Just have your D3D and GL classes as the base classes and the Renderer derived from them.

Another idea would be to have the render class use the GL and D3D classes. Have a method for switching between them like before, but use a function pointer and set it to a member of which renderer is being used.

[edited by - xds4lx on November 6, 2002 10:36:53 AM]

Share this post


Link to post
Share on other sites
ZE,

Considering many users don''t often switch between fullscreen and windowed mode for very many reasons, you might consider the quick and dirty method (memory-leak free, of course ) by killing the window, recreating it, and restoring textures from copies in memory. It''s fairly quick, and will let you proceed with the rest of your engine.

What I did for my Glide/D3D/OpenGL system wrapper was write window creation schemes for each of the APIs, switching modes with a boolean flag (though I was never sure if the OpenGL one worked properly, I think my Glide drivers at the time were dying when I called that code).

Have you also looked into GLUT, which is free from open-source constraints? Though this might constitute more code rewriting than the end result is worth, as it is an extreme abstraction from probably most of the code you''ve already written.




MatrixCubed
http://MatrixCubed.cjb.net

Share this post


Link to post
Share on other sites