Scrolling Game Development Kit Forum
SGDK Version 2 => News and Announcements => Topic started by: bluemonkmn on 2008-01-14, 06:45:25 AM
-
I am beginning work on SGDK version 2.1 in which I'll try to switch to and/or add support for OpenGL. So far I managed to write a small test program based on CsGL (C# wrapper for OpenGL) that draws an image on the screen, but it ignored the transparency info, so things are progressing slowly. If any OpenGL experts out there would like to offer their assistance, it would be appreciated.
I'm also upgrading the SGDK2 project to work in the Visual C# 2008 Express environment so that everyone can easily edit/use/debug the program and their generated games in a freely downloadable, full-fledged development environment. This also means it will use a newer version of the .NET framework, so Vista users won't have as hard a time downloading an old framework.
-
good to hear.
but could you give me an example of
everyone can easily edit/use/debug the program and their generated games
i can't imagine what these concretely means.
-
so this means sgdk2 and it's games could run on linux/mac?
-
Sounds great. OpenGL integration would considerably increase the chances of cross-platform development. It stinks that you are having trouble at the moment. Transparency and full PNG support is one of the best things about SGDK2. I can't imagine going without it. Unfortunately, I am primarily a C# programmer, and have little experience with OpenGL. I hope you are able to find a little help for this. Support for Visual C# 2008 is nice, though I think updating it to work with the latest version of the .NET framework is probably more important.
-
good to hear.
but could you give me an example of
everyone can easily edit/use/debug the program and their generated games
i can't imagine what these concretely means.
The games generated with SGDK2 are somewhat different than those built with SGDK1. Rather than being in a GDP file that requires GDPlay.exe or gamedev.exe to run, it actually writes all of the source code in C# to files, then compiles it into a single standalone executable. Those files are not deleted after the compile is complete, however. You can open the project in Visual C# 2008 Express and edit all of the code that runs the game directly, including the code from the Source Code folder as well as all of the generated code based on sprite rules, plan rules, and so forth.
This gives a better debugging environment for finding errors when developing your own source code, since you can step through the program line by line to see where problems crop up.
-
I took a few missteps at the beginning here, but I suppose one should expect to research a few technologies before settling on one. I first tried CsGL, which was last updated in 2002, but seemed like it must at least be stable. Then I discovered Tao.OpenGL, and started looking into that. But I was concerned about the portability of that since it required Tao.Platform.Windows.dll, which doesn't exist on other platforms. I think I've finally settled on OpenTK for the OpenGL wrapper that I'll be using. I converted my test program to use that and it works nicely. Next I'll start editing SGDK2 code. OpenTK looks like it's very careful about cross-platform support. It's in alpha right now, so it's not necessarily fully implemented or stable, but it least it should be up-to-date. And I can pull in updated versions as they become available.
-
Hmmm...that makes me think of something. One of the things I've been wanting to do with SGDK2 is create a game with a non-standard screen aspect ratio. That is to say, it would be vertically oriented, rather than the standard 4:3. I would want to do this because I am interested in using SGDK2 to create a shmup. And many shmups scroll upwards and have vertically oriented screens. (screens that are taller than they are wide) The existing source code doesn't allow for this, and I can't seem to save edits that I make to the source code either. But I know from looking at the source code that this should be possible. Can I fire my game up in Visual Studio and add new screen resolution options?
-
If you want to save your edits to the source code, you have to edit it within the SGDK2 IDE, or edit it in Visual Studio and then copy your edits into the proper file in the SGDK2 project's SourceCode folder in the IDE. Each time the game is compiled, all the files in the generated project folder are overwritten by content that is generated based on the SGDK2 file. However, if you happen to be editing code that is not contained in the source code folder in SGDK2 (because it's one of the few bits that are hard-coded into the code generator) then yes, your only choice is to load the project into Visual Studio and edit it there. Of course the you can never compile your project in SGDK2 again without overwriting what you did... you would have to re-apply your changes every time you compile from SGDK2.
On the topic of screen size, though, I noticed an interesting thing while working on my OpenGL test program. It's really easy to make the screen resizable and have the contents stretch to fill the window. Maybe I'll allow that in 2.1 instead of making the window a fixed size. Also, it'd be kinda cool to be able to zoom out in the map editor! I could really open up control over sizes and aspect ratio. You could define any size screen that you want to work with, and then if it doesn't fit the display, it can just be scaled. I suppose I'll need two sizes: Game Size for defining how much graphics you want to fit on the screen (640x480 pixels worth for example), and Viewport size for defining how big it should be displayed (by default). Viewport will change as the window size changes, and will have to fit a full screen resolution if the player switches to full screen (though that's not supported in OpenTK yet). I wonder if there's a better term for "Game Size".
BTW, I'm thinking full screen is not such a necessary feature... do many people find that important? I suppose it might improve performance in some environments, but ideally, I think a lot of people like to play within a window.
Ooh, I think "Native Size" might be a good term instead of "Game Size"
-
please don't delete the fullscreen option...
how about playing the game in 800x600, while the rest of the screen is black? is there a possibility for that? i would think that is a cool thing, because some games would blur at fullscreen, but always having the normal desktop background while playing annoys me.
giving the user control over screen sizes is a good thing. a few months earlier i saw i quite cool game in extreme wide format. maybe 100px high, but 800 wide. that was cool! :laugh:
-
zooming in and out in the map editor would be great! ;D
-
zooming in and out in the map editor would be great! ;D
word.
-
Good News! Just now I managed to get the map editor up and running on OpenGL, scrolling and all, and all the sample game's tiles were showing up. It was a bit blurry (unnecessary anti-aliasing going on?) and I'm not sure the colors were as nice as they should have been, but hopefully I can resolve these issues with further testing and refining. The tile animation preview is also running on OpenGL.
Woohoo :nerd:
Edit: BTW, for anyone following the source code, there's a new branch for 2.1 in the subversion repository at branches/SGDK2IDE2.1/
That's where I just checked in my progress with OpenGL. Note that I did not include OpenTK.dll in source control so you'll have to get that separately.
-
I've worked out all the problems I'm aware of in the IDE so things are working pretty much like they did with DirectX. Next step is to transfer all these updates into the project templates so the projects are using DirectX. Still not sure if OpenTK supports switching between full screen and windowed mode, though. It looks like they intend to, but it wasn't implemented in the last version I downloaded. I'll check again and maybe post a message to see if they are implementing it soon. It's probably not so important for the IDE, but might be more relevant to the generated games.
-
In the process of implementing OpenGL in SGDK2, I've noticed that OpenTK has a few shortcomings (isn't done yet), so I've started to investigate and experiment with OpenTK code a bit, and may be contributing to the OpenTK project as well. Namely, some of the text drawing features in OpenTK are incomplete. I've already suggested an alternate/improved mechanism for positioning text characters when preparing text for drawing. We're still working out the details of what code is ideal for that (needs to be clean and optimized).
-
Well, I finally got a few hours to work on the OpenGL conversion, and now I have SGDK 2.1 functioning well enough to generate, compile and run the sample project without any references whatsoever to DirectX. There's still a problem with drawing messages because the OpenTK text drawing functions aren't done yet. But all the tile and sprite drawing look good, and the DirectInput references have been replaced with API calls and input devices seem to be working OK.
On the down side, I don't think it's going to be straightforward to continue to support DirectX. OpenGL/OpenTK have a nice mechanism to draw transformed frames by specifying the corners of the output quadrilateral whereas with DirectX I had to use a transformation matrix to draw a transformed frame. That affects one aspect of the code generator -- it needs to know that frames are constructed using corners instead of matrices. But I don't think I want to support both mechanisms unless it's really important. How would folks feel about it if I abandon DirectX support?
The code is checked into SVN for anyone eager to see how it looks/performs. It's not quite finished yet, though.
-
I'm very happy to report some unexpected side benefits of converting to OpenGL. There's a significant performance improvement. I just created a project in SGDK2.1 (OpenGL/OpenTK) and then loaded the same project into the old DirectX version of SGDK2 (this is not a problem for relatively simple projects with no custom code) and found some interesting results comparing the performance:
4800 8x8-pixel tiles on screen + 500 8x8-pixel sprites active:
DirectX = 31 fps
OpenGL = 72 fps
4800 8x8-pixel tiles on screen + 1000 8x8-pixel sprites active:
DirectX = 25 fps
OpenGL = 49 fps
So it appears performance is about double or better with OpenGL.
-
wow, good to hear! :)
-
On the down side, I don't think it's going to be straightforward to continue to support DirectX. OpenGL/OpenTK have a nice mechanism to draw transformed frames by specifying the corners of the output quadrilateral whereas with DirectX I had to use a transformation matrix to draw a transformed frame. That affects one aspect of the code generator -- it needs to know that frames are constructed using corners instead of matrices. But I don't think I want to support both mechanisms unless it's really important. How would folks feel about it if I abandon DirectX support?
Any opinion on this, Tanja?
-
I imagine that almost nobody using SGDK2 just yet is so engrossed in the technical details as to have much of an opinion. The extent to which DirectX was being used in the previous version is not so extensive as to present itself as problematic if somebody who knew DirectX but not OpenGL used SGDK2.
I'm not sure if the change requires a change in the SGDK2 file format, (seeing as how you say it no longer needs matrices?) but it would be nice to provide an auto-upgrade system from previous file versions.
-
No change in file format. I still use matrices to define how the frame is transformed, but when the code is generated, I convert the frame definitions into corner points using the matrices. And I think the only parts that need to be upgraded are mainly things that can't be upgraded automatically like custom code that references DirectX objects. I provided a OpenTK version of the Message code object. It doesn't work very well yet because OpenTK doesn't do text very well yet, but hopefully soon. I haven't looked at the other importable objects yet, but I'll provide converted versions of those too. I think upgrading a project will be as easy as resetting the source code and re-importing the custom objects (or making the necessary tweaks manually in the case of sprite definitions that are referencing DirectInput.Keys).
-
do as you like, and what's the best for sgdk2. this frame-corner thing sounds nice. i think we can change our directX-related rules without too much stress.
-
Good news: I got full screen support working... at least in my environment -- not sure how it will behave on others' hardware/drivers. And I think it will be much nicer than DirectX was if you have to debug because it doesn't lock the display. It just changes the resolution and makes the window take up the whole screen (removing menus and borders). So if some error happens, you won't be stuck unable to access other programs or debug it.
Now I just need to see if I can get OpenTK to finish the font support so I can fix the word wrapping for message boxes. Then I'm not aware of any other changes that need to go into the initial OpenTK/GL release before I let it out. I just wish I knew why the one system can't run any OpenTK-based .NET programs.
Oh, I also upgraded FMODEx to version 4.14.3. I didn't implement any new features based on this version, and I don't know what new features might be available, but it's better to have a version that is at least still available on the FMOD web site :-[.
-
Quick question... How is it that DirectX was able to run with non-POT-sized textures while OpenTK cannot on the same system? Did you take this in to consideration? Also, have you removed all DX references in the IDE as well? Or is that still en route?
-
Allow me to respond in reverse order.
1) Yes, I have removed all DirectX referenced from the IDE. I noticed yesterday that I still had a reference to DirectInput and DirectX in the IDE, which surprised me because I thought I had removed all references. So I removed them and everything was fine. I guess I removed all the code and just forgot to remove the references :).
2) Maybe the DirectX drivers for the particular card support non-POT-sized textures and the OpenGL drivers report that it doesn't? That's a good question. I didn't do any explicit validation of this feature in DirectX -- just tested support for alpha blending I think (which, come to think of it, I haven't done for OpenGL). I'm gonna have to do some more investigation on this topic. Too bad I don't have a video card with this problem to do testing with. I do have a new TV, though... I'll post about that in off topic.
-
I'm on vacation for a week and a day starting today, and I won't have much web access, so don't expect any replies from me for a week. But don't worry, I'm still planning to wrap up SGDK 2.1 as soon as the OpenTK library finishes its implementation of text rendering, which is coming up soon, I think (I helped work out one of the issues to move things along). Meanwhile I'm going to try to get SGDK 2.1 to compile and run under Ubuntu and see how close we are to officially supporting Linux. The release of 2.1 would be a good time for people to get their work recognized if anyone wants to create super fun little demo games... something like the existing sample project, but longer or more fun perhaps?
-
how is it going on?
-
I'm still waiting for OpenTK to provide proper font support.
-
Are you making any other changes as far as the requested features list? Since you're not working on bug fixes, it seems like a good time to do so
-
No, I've also been addicted to video games :-[
But I'll see if I can fit some of that in.
-
Recently I finished fixing the error that occurs when you update a layer's size while the map editor is displayed. And yesterday I added support for cutting (not just copying) rules and children. So progress is being made. If OpenTK doesn't get moving and provide proper font support soon, I may take a suggestion durnurd made and just implement tile-based text drawing (as many games seem to do anyway) to get something out there for 2.1.
-
good to hear!
-
yep, cool.
if you are going to make tile-based text-drawing, does this mean there will be a bitmap with the alphabet?
maybe you could make a picture that is displayed above or beside the message, while you're at it.... ;D .... with an option for different emotions of the speaker ....
-
One thing at a time. Yes, there will probably be some "Font" Tileset parameter for the message function, and the default project will have a default "Font" included. Then maybe putting a picture on the left side of the message would be as simple as putting a strange letter (like that accent you were using, Tanja ;)) on the left (whose image is much bigger than a normal tileset tile) and making sure that your other letters don't overlap it. Unfortunately providing a preview like in version 1.x won't be easy or nice because the SGDK2 plays dumb about what the functions do. It just knows the name of the function and the parameters, so it doesn't know if you've selected a message function, or if you have, how the message is displayed, unless I hard-code a lot of assumptions, which is messy. We'll see how it goes.
-
Note to self (that everyone is welcome to share). Here's the code to generate the graphic sheet image for the font:
[code]
using (Font fnt = new Font("Lucida Console", 11))//, FontStyle.Bold))
{
charPic = MakeFont(fnt, new Size((int)fnt.Size+2, fnt.Height+2), 24);
}
private Bitmap MakeFont(Font font, Size charSize, int cols)
{
int rows = (int)(Math.Ceiling(96.0f / (float)cols));
Bitmap result = new Bitmap(charSize.Width * cols, charSize.Height * rows, System.Drawing.Imaging.PixelFormat.Format32bppArgb);
using (Graphics gfx = Graphics.FromImage(result))
{
using (System.Drawing.Drawing2D.LinearGradientBrush br =
new System.Drawing.Drawing2D.LinearGradientBrush(new Rectangle(0, 0, charSize.Width, charSize.Height), Color.White, Color.SlateBlue, System.Drawing.Drawing2D.LinearGradientMode.Vertical))
{
byte[] charBytes = new byte[96];
for (byte charIdx = 33; charIdx < 128; charIdx++)
{
charBytes[charIdx - 33] = charIdx;
}
char[] chars = System.Text.Encoding.ASCII.GetChars(charBytes);
chars[94] = '
-
I think a good use of the System.ComponentModel attributes could be applied in your case to get around hard-coding things. If, for example, you used the System.ComponentModel.EditorAttribute, it could be used to preview various function calls in any way the coder wanted, and could also provide an interface for editing the arguments that's better than choosing from a generic dropdown list.
-
Interesting thought. I might have to try that. BTW, where did you get your new avatar?
-
I was looking through that Lost Garden website and saw some other graphic sets he had available for download, including a complete RTS section. That's one of the building units being built, running, and being re-consumed all together.
-
Neat. :)
-
I have committed a set of changes to SVN (for anyone who is interested in compiling the latest source code) with a complete and integrated solution for displaying messages. I have not added the XML documentation text for it yet, nor tested it with arbitrary images included in the message, but it should work. I'll keep working on it. No longer are messages a separate customizable object. There is one "ShowMessage" function that simply accepts a string for what to show. And now all the other options are split into separate functions like "SetMessagePosition" and "SetMessageDismissal" for determining where the message appears and how it is dismissed.
-
oh joy! can i have the current version to test it out?
-
If you want the current version, you're going to have to compile it. That involves finding an SVN client first, to download the files, then you'll need Visual C# 2008 Express Edition to actually compile it. I tried with just the .bat file, but it seems to be out of date.
If you don't want to download an SVN client, you can download the latest version in a TAR file here:
http://sgdk2.svn.sourceforge.net/viewvc/sgdk2/branches/SGDK2IDE2.1.tar.gz?view=tar
But then you'll need a way to unTAR the files, which I think WinZip can do.
If you want to go the SVN route, I suggest TortoiseSVN (http://tortoisesvn.tigris.org/)
Then you want to actually check out the SVN files, which this url (http://sourceforge.net/svn/?group_id=152001) has instructions for. Note, you'll want to append "/branches/SGDK2IDE2.1" to the path ("svn co https://sgdk2.svn.sourceforge.net/svnroot/sgdk2/branches/SGDKIDE2.1 sgdk2") to get the latest version
Once you have the files on your computer, you can try using the makesgdk2.bat file to compile, but it probably won't work. At the very least, you have to edit the file and replace "path %windir%;%windir%\System32;%windir%\Microsoft.NET\Framework\v1.1.4322" with "path %windir%;%windir%\System32;%windir%\Microsoft.NET\Framework\v2.0.50727"
Then just double-click on the batch file. It will probably fail, however. There are other ways to compile the project, but the easiest, in my mind, is to just download Visual C# 2008 Express Edition, which you can get from here:
http://www.microsoft.com/express/download/ (You will want the green one)
Once you have that installed, just double-click on sgdk2.sln, which will open the file in C#. At this point, you can build the project by (I believe) pressing CTRL+SHIFT+B. This will create a directory called "bin" under the root sgdk2 directory. Go there. Under that you'll find another directory, either Debug or Release. Go into that, and you should find sgdk2ide.exe, which you can run.
-
wow. ??? okay. i'll try this.
-
heh...good luck! ;)
-
I tried with just the .bat file, but it seems to be out of date.
D'oh! I forgot about the BAT file. Gotta fix that.
-
Good luck to that too :)
-
Hey, I just realized/remembered, .NET 2.0 and later comes with an MSBuild utility so I think that will make the command line build process much simpler. Can anyone else test this for me on a system that doesn't (or does, whatever) have a C# development environment installed? Go to the directory where all the SGDK 2.1 source code is and run the following command:
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
You don't even need to pass any command line arguments. It will find the .SLN file in the current directory and compile it. If you don't have a v3.5 directory, try installing .NET Framework 3.5 (from Windows Update?).
-
So... are you actually using .NET 3.5 now? I tried it with 2.0 and it didn't work (bad sln file format version).
I couldn't open it in the VS IDE either. When I opened the .csproj file alone in the IDE, it worked fine. After adding the Reflect project, downloading OpenTK and extracting the two DLLs into the directory, and changing all the "var"s to the real variable type, it compiled and ran in the IDE just fine.
Also, after looking at the current implementation, obviously, you will eventually change the need for "CoolFont". Other suggestions that you may or may not have already planned, based on what I've worked with on cellphone games:
1. A function/property "(Set/Get)CharSet" which takes a string defining what characters are in the image in what order.
2. A function/property "(Set/Get)TextColor" which can change the color of the font, since the drawing is using graphic sheets instead of framesets.
3. Possibly similar functionality for scaling, for the same reason?
3. Determine the base character size by image cell size
In our framework at work, DrawString actually takes in an X, Y, String, and an anchor, which is a logical OR on some flags: TOP, VERTICAL_CENTER, BASELINE, BOTTOM, LEFT, HORIZONTAL_CENTER, and RIGHT. The anchors correspond to what the X and Y are actually pointing at (the BOTTOM HORIZONTAL_CENTER of the text for example). It then offsets the x and y based on how big it calculates the string to be based on those flags.
There's also another function, DrawStringInRect, which takes in the string, a rectangle, and anchors. The rectangle defines what rectangle to stay inside. Again, the anchors can center the text within the rectangle, or right-align it or whatever.
Of course, you couldn't really fit any of those into one call with three parameters. Unless you did that visual editor idea with the attributes thing, which would then have one parameter be the whole rectangle.
-
So... are you actually using .NET 3.5 now? I tried it with 2.0 and it didn't work (bad sln file format version).
The project uses the latest version of the C# development environment, but targets .NET framework 2.0, so I think you need .NET 3.5 to compile the project, but only 2.0 to run it.
Also, after looking at the current implementation, obviously, you will eventually change the need for "CoolFont".
Why is that obvious? I was thinking about leaving that in as the default font, allowing users to change it, but not delete it (if they plan to be doing any text output). I don't prevent them from deleting it; you'll just get an error message if you try to output text and have deleted it from your project without replacing it appropriately with something else.
1. A function/property "(Set/Get)CharSet" which takes a string defining what characters are in the image in what order.
I already have "SetMessageFont" which allows you to change the font used for messages by specifying an alternate tileset.
2. A function/property "(Set/Get)TextColor" which can change the color of the font, since the drawing is using graphic sheets instead of framesets.
3. Possibly similar functionality for scaling, for the same reason?
3. Determine the base character size by image cell size
For messages, it uses Tilesets, not Framesets or graphic sheets. The DrawText function of Display is only intended as a very basic fallback for outputting debug information. Most other text should be output using the message functions added to GeneralRules, or by other functions to be added later or as custom code.
In our framework at work, DrawString actually takes in an X, Y, String, and an anchor, which is a logical OR on some flags: TOP, VERTICAL_CENTER, BASELINE, BOTTOM, LEFT, HORIZONTAL_CENTER, and RIGHT. The anchors correspond to what the X and Y are actually pointing at (the BOTTOM HORIZONTAL_CENTER of the text for example). It then offsets the x and y based on how big it calculates the string to be based on those flags.
I have something similar, but simpler:
public void SetMessagePosition(MessageView ViewOption, RelativePosition Position)
-
The other major change in 2.1 besides OpenGL support is upgrading to .NET Framework 2.0, and as it turns out, NDoc, which was being used to generate the coding reference documentation, does not support .NET 2.0. So I spent this weekend looking around for an alternative and found Sandcastle and the Sandcastle Help File Builder -- a UI that makes Sandcastle friendly to use (makes it look very similar to NDoc and even imports NDoc project files). So I made a few adjustments to the documentation to make it work in with Sandcastle, and the result is very nice. Everything is in one help file now, compiled by one process instead of being split into the UI help file compiled by HTML workshop and the coding reference compiled by NDoc. The new documentation compiler is very flexible and allows all the other content to be included as the help file is compiled. So I've got that all worked out, and it seems to be working well and looking very nice. Next I'll update the sample project to work with the new message display functions that are based on tilesets instead of system fonts, and then maybe 2.1 will be ready to release. Oh, and I must remember to try showing a graphic with the text of the message as Tanja suggested too. I keep forgetting to test that, but that would be a good thing to demonstrate.
-
Yay! hope i can test the new sgdk soon.
-
hopefully this one will work on older computers like mine :pray:
-
hopefully this one will work on older computers like mine :pray:
It's not getting any older. If the old one didn't work, the new one almost certainly isn't going to work.
-
hopefully this one will work on older computers like mine :pray:
It's not getting any older. If the old one didn't work, the new one almost certainly isn't going to work.
i mean since it is using Open GL this time, which works just fine on mine
-
what, and directx doesnt?
-
it depends on what versions, DX5 used in SGDK1 works fine, but anything above 8 doesnt work as well or not at all
-
wouldn't there be a way to force lower directx levels in your video driver options?
-
not that i know of... ??? i'll just blame the video card, again! (this time its a Voodoo5)