Scrolling Game Development Kit Forum
SGDK Version 2 => Help, Errors, FAQ => Topic started by: Wyzemann on 2011-02-12, 10:01:00 PM
-
I recently found SGDK and I am intrigued by it, especially its scripting features. I have been playing with version 1 since version 2 uses opengl which doesn't work on my system. I was hoping there was a way to get it to work since I spend most of my time on this computer anymore.
It may be that my integrated video board is not compatible with SGDK. However, it does seem to meet the minimum requirements.
I have updated the video driver to no avail. It is running Windows XP Home edition SP3. (Running on AtomN450, 2GB RAM).
GPU Shark v0.3.2 utility provides this information:
GPU: Intel GMA 3150
Memory size: 384 MB
Open GL Platform: Intel Pineview
Open GL 1.4.0
I went through the tutorial step by step and when I got to the map editor it produced the following error:
An error occurred while drawing the display in the map editor. In order to attempt to avoid fatal errors...
Details:
System.Exception:InvalidEnum
at SGDK2.Display.CheckError()
at SGDK2.Display.DrawFrame(TextureRef texture, Rectangle sourceRect,Point[] corners,Int32 offsetX,Int32 offsetY)
at SGDK2.Layer.Draw(Display Display, Size ViewSize)
at SGDK2.frmMapEditor.MaoDisplay_Paint(Object sender, PaintEventArgs e)
A second dialog box appears
GL_ARB_texture_rectangle may be required for proper operation. The current video driver does not support this feature. Try updating your video drivers.
Then after I click OK the first dialog appears again. Then it just doesn't work.
I am aware of a similar problem that was mentioned in the forums. It was actually repaired by changing the source code to omit error detection. That was a problem with OpenGL 3.x I did this and it didn't change anything. Also note that it does the same thing if I try to run any games created with SGDK 2.1.x
The directX versions of SGDK work without any issues.
Is there a workaround for this or is it simply incompatible? Is there a way to get the latest SGDK to use directX so it will work on my netbook?
Chris
-
As indicated by the error message, your hardware and OpenGL driver need to support GL_ARB_texture_rectangle. Try running an OpenGL diagnostic utility such as OpenGL Extension Viewer (http://www.softpedia.com/get/Programming/Other-Programming-Files/OpenGL-Extension-Viewer.shtml) and check the "Extensions" section for "GL_ARB_texture_rectangle" in the "Extensions" folder's "ARB" branch. I don't know why some hardware/drivers do not support this. It seems like a really simple thing. If you can find it in the list, I would be interested to know what it looks like (what child items appear under it) and if it is supported on your system.
-
I downloaded and ran the OpenGL extension viewer.
ARB_texture_rectangle is not there.
Here is the list:
GL_ARB_depth_texture
GL_ARB_fragment_program
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_window_pos
WGL_ARB_buffer_region
WGL_ARB_extensions_string
WGL_ARB_make_current_read
WGL_ARB_pbuffer
WGL_ARB_pixel_format
-
Is there any reason you use the ARB_texture_rectangle extension? Would it be that much more difficult to draw polygons as necessary? It seems like it would be more supported.
-
I use texture-rectangle because it allows me to use pixel coordinates and NPOTS textures. I'm rather fuzzy in this general area, though ... I don't know what capabilities require what features to be present or what my alternatives are in drawing 2-D graphics while applying transformations. I found one solution, but don't know what others might be available.
-
Thanks for looking into it. I appreciate it. Looks like I'll just have to stick with version 1 for now.
Chris
-
My experience is mainly with OpenGL ES, which handles drawing textures differently, but the problem of pixel coordinates and NPOTS textures is shared. The problem can be solved relatively simply using a Texture wrapper class that determines if the graphics card supports NPOT textures and if it doesn't, creates an image at the next largest power of 2 at runtime, draws the base image into that image, then stores the scale necessary when drawing the image. As for pixel coordinates, that could also be solved in the Texture wrapper class.
Out of curiosity, do you do any optimization when drawing multiple frames from the same texture? On maps, for example, if all of the tiles are from one frameset which are all from one graphic sheet, all of the tiles could be draw in one draw call using glDrawElements. I suppose most of the time it's not too big an issue as far as speed is concerned, since it's only a 2-D game, but it's a potential bottleneck if you've got lots of tiles onscreen at the same time that could be remedied. I don't know if it would be easy or if it would require a lower-level change, like requiring tilesets to be defined as taking all tiles from one graphic sheet, or something. It could possibly be something you detect at compile time, whether to enable that method of drawing tiles or not, depending on where tiles are coming from.
-
I think there is optimization when drawing multiple frames from the same texture. When DrawFrame is called on the display, it will only call functions to output texture coordinates and viewport vertices (nothing to select a texture) if the previous drawing operation was also DrawFrame and used the same texture. So that works pretty well.
I did try to go back to DirectX when the previous person who found a problem with ARB_texture_rectangle had this same problem, but I gave up when I discovered that DirectX isn't as flexible as OpenGL when it comes to 2-D transforms. I have to supply the original transformation matrix, not just the 4 corner points that I want to output. And getting a transformation matrix out of 4 corners is much more difficult that getting 4 corners our of a transformation matrix. Since I had already updated SGDK2 to track only the 4 corners and discard the transformation matrix, I gave up. So maybe I'll have to attack this problem again going after your solution instead of trying to go back to DirectX. I also neglected to improve the error reporting for sprite rules and plan rules. So many things to do ... so much TV to interfere with getting any of it done.
-
Well, I can try to clean up the prototype for error reporting that I have working somewhat and upload that. It's all colorful and stuff, even.
If you decide to do anything with having all graphics be from the same texture and using glDrawElements, you could still use four points and not have to deal with transformation matrices, and draw all the tiles at once. It would be a bit of a leap from how things are done now, though.
-
I thought I was drawing all the tiles at once. I guess there's a way to do it even more at once. But I'm not sure it's worth it. I'm more interested in making SGDK2 more compatible than making it perform better at the moment. Runtime performance doesn't seem to be much of an issue. I think I just need some time before I can look into the error reporting thing, whether it's reviewing your code or writing my own. How do you feel about your code -- is it clean, or do you think it deserves some review?
-
Well, I wouldn't put it in as-is. It seems pretty stable, so at least it won't crash or anything, but it might be inaccurate at times, depending on if you have multiple copies of the same rule doing something wrong in the same way in a single rule list.
As for compatibility, it seems like using glDrawElements or glDrawArrays would be the most compatible with any graphics card available. You'd just have to deal with non-pixel coordinates and possibly scaling of images drawn into power-of-two textures, if the card doesn't support NPOT textures.
-
I don't think glDrawElements would be any more compatible than glVertex2 and glTexCoord2, would it?
-
Those methods don't exist in OpenGL ES, so I'm not familiar with them, but I imagine it's just another way of doing the same thing... is that what you're using now, or are you doing something different to use the ARB_texture_rectangle extension?
-
That's what I'm using now. Those functions have different behavior depending on whether I've created the texture using GL_ARB_texture_rectangle or not, I think. I think the same functions would be used if I weren't using GL_ARB_texture_rectangle.
-
Ah, I had assumed the extension was used in how you draw, not how you create textures. So you could probably create a texture wrapper class to handle all that stuff as necessary rather than relying on the GL_ARB_texture_rectangle extension to do it for you. Or you could test to see if the extension is supported before deciding whether to use a wrapper class or not.
-
If I do all this, I hope there's still someone around to test that my fix worked. I think I should handle both absence of support for GL_ARB_texture_rectangle and NPOTS textures. It shouldn't be too hard because My texture is already a wrapper class, which I implemented as I converted from DirectX to OpenGL.
-
If you have anything you would like to test on my netbook just send me an e-mail and I would be glad to do it.
Chris
-
If my test is correct, the solution is shockingly simple. To anyone who was having problems with SGDK2 on OpenGL, can you run the following test for me?
1. Create or load a sample project in the IDE (you can do this without going into the map editior).
2. Replace the contents of the Display.cs file in the project's SourceCode folder with the contents of the attached Display.cs file.
3. Run the project
Let me know if that works.
Edit: Attachment removed in favor of updated version below.
-
I tried the following procedure, and it failed.
I downloaded the Alpha and Omega project.
Under the File menu, I selected "Generate project" and ran the project. As expected, the texture rectangle could not be found.
Then I replaced the display.cs text with the text from the attached file, and saved the project.
Again I generated the project and ran the project (Ctrl+F5)
An error message appears:
Note I will truncate file paths with ... for brevity's sake. The files are in their default locations.
Error
A fatal error occurred initializing or running the game:
at Display.CheckError() in
... \Display.cs:line 885
at Display.Flush() in
... \Display.cs:line524
at GameForm.Run() in
... GameForm.cs:line 243
at Project.Main()
... Project.cs:line 107
Line 885 of display.cs is:
throw new System.Exception(ec.ToString());
I attempted to invoke a message box to see the contents of ec but it didn't work because it could not be converted to a string.
I am a rank beginner when it comes to programming in C. Perhaps this is an array and I will need to loop through it.
In bypassing the error code I was able to get into the game. The sprites seemed to work but there were many blank tiles, including
text tiles.
Chris
-
Can you use the suggested sample project instead of downloading a project? I don't expect the results will be much better, but I just want to be sure of what is being tested. Just select New->Sample Project from the file menu.
How did you "bypass the error code"?
Did some sprites appear as they should?
I wonder if the problem is that your driver also doesn't support graphic sheets (textures) whose size is not a power of two. That would probably also be an easy fix.
The ec variable is already being converted to a string and displayed in the error message you copied, but either you missed a piece or the error message was empty. The message comes immediately after the text "running the game:" and before the first "at".
-
I didn't realize there was an official sample game. Sorry about that.
This time I used winspy to capture the text from the message box. I truncated the paths to "..." for brevity's sake:
A fatal error occurred initializing or running the game:
System.Exception: InvalidValue
at Display.CheckError() in ...\Display.cs:line 885
at Display.DrawFrame(TextureRef texture, Rectangle sourceRect, PointF[] corners, Int32 offsetX, Int32 offsetY)
in ...\Display.cs:line 486
at LayerBase.Draw() in ...\LayerBase.cs:line 423
at Menu_Map.Draw() in ...\Menu_Map.cs:line 78
at MapBase.DrawAllViews() in ...\MapBase.cs:line 269
at GameForm.Run() in ...\GameForm.cs:line 227
at Project.Main() in ...\Project.cs:line 107
Attached is a screenshot from the game. I "bypassed" the error by removing line 885 and running in debug mode.
The sprites are animating and a lot of it seems to be working. As you can see it is missing tiles, including the text tiles, which might have something to do with this error.
Note my netbook's screen resolution is too small to get the whole thing (1024 x 600).
Hope this helps
Chris
-
Oh wow! This is promising. It looks like text is the only thing that failed. I will look into this more when I get home today (I hope).
-
OK, try this version of Display.cs.
-
Looks like that worked. I also "Generated" the project and ran the .exe and there were no issues that I could see.
In debug mode however was a very minor glitch. There was some slight pixel garbling in the black tile between the words CONTINUE and GAME in the first screen, but it only occurred in the debug mode, not when it ran from its own exe. I attempted a screen capture, but it was invisible to the screen capture. Maybe it's just because I have a piece of junk video board.
Thanks for working on this way cool software. I'm looking forward to seeing this implemented in the level editor.
Chris
-
Hooray -- I will begin updating the SGDK2 IDE to match and release another version soon. Maybe I can get the improved error handling in there too while I'm at it.
-
Can you try http://sgdk2.enigmadream.com/support/SGDK219.zip (http://sgdk2.enigmadream.com/support/SGDK219.zip) and let me know if it works on your netbook before I publicly release it? (Anyone who had problems with OpenGL when the DirectX version of SGDK2 worked, I'd appreciate your replies.)
Also, durnurd, did your change for tracking down errors in sprite and plan rules work for cases when the project was compiled to a temporary location, or only when it was compiled to real files in the project directory?
-
It appears to be running successfully and the level editor worked without any flaws. It is working very nicely.
I do have more information about the pixel garbling bug on the startup screen that I mentioned earlier.
I assumed the problem was something outside of the OS, but I found it didn't capture because it was blinking very rapidly. After multiple attempts I was successful at at capturing. I notice the strange blinking block changed the next time I loaded it.
The first attachment is a screenshot from the first launch from the game's compiled .exe file.
The second attachment is a compilation. I cut out the block for the subsequent two runs. (There could have been another run I missed) and pasted them so you you see two of them, each on subsequent runs, presented with what appeared to be the last tile shown for runs afterward.
I actually recompiled and did a few more trying to look for a pattern, but different blocks appeared. Some of them look like game tiles. Sometimes they were not there at all. It looks like it is getting some kind of graphic data from different places and is displaying it on that tiny block.
Like I said before, it only happens on this screen and does not seem to interfere with anything. But I did say it did not apply to the generated exe file. This was inaccurate, as it does manifest both with SGDK running in addition to it and without as I discovered.
With that being said, I did try two other games, including Alpha and Omega, and the Turret demo and did not run into this problem. It may be unique to your sample game.
Anyway I am confident enough to begin work on my own game. Keep up the good work.
Chris
-
I think the change I made relied on filenames somewhat, so temporary files wouldn't work.
-
Now that I see exactly what you mean about the position of the corruption, I think I realize what's going on. There's an error in the design of the menu map. Fortunately not a problem with SGDK2 itself. Here's how you can fix it if you care to test it:
1. Open the "Disabled Continue" layer of the "Menu" map in the editor.
2. From the "Layers" menu un-check the "Letters" layer to hide the main layer.
3. "Continue Game" appears in gray in the top corner. Move the mouse between the words.
4. Notice the status bar says Tile @X,Y: 0. That means the transparent tile is at that position.
5. From the tile selector, select the last tile (#207).
6. Click between the words to change the tile #0 to tile #207.
Now when you run the game you should not see the corruption any more. The cause of that behavior was that "Continue Game" got copied to the main layer as the game was starting, and since the transparent tile overwrote the black tile on the main layer when that happened, there was never any opaque tile there to erase whatever was in video memory at that location.
Thanks for helping me get SGDK2 to be more compatible with other video hardware. I hope everyone who had problems with the OpenGL version will give it another chance now. I wish I had realized earlier that it would be so easy.
I'm going to see if I can do anything about improving that error reporting before truly releasing 2.1.9.
-
That fixed it.
Right now I'm making models in Blender 3d to render to 2d and learning how to rig meshes for animation, which for me is more of a learning curve than I expected. So it will probably be some time before I get into the game engine other than playing around with it. If I don't get back in a day or two please feel free to e-mail me if you would like me to do any further tests.
Chris
-
I tried out the latest version. It looks like it points to the wrong rule on occasion when finding what rule a line of source code belongs to. Specifically, I had three rules. I appended a fourth rule that called a non-existant function, then inserted a rule as the second in the list that called the same nonexistant function. The bad rules were #2 and #5, but when I tried to compiled, it said the errors were on #3 and #5. The drawing seems to work fine though.
-
Odd because it doesn't even look at the function being called. It just uses the rule name, which has to be unique. I know there's a problem with "And" and "Or" rules because they don't output the rule name in the generated code, but that should have erred in the other direction (it moves backward/upward until it finds a comment representing a rule name). Oh, but I knew the line counter was off a bit... I thought it wouldn't matter because the lines would be sufficiently separated by braces and comments and code and such, but perhaps not. I should probably subtract one or whatever.
At least it gets close. I should also improve it by making it look not only at the rule name, but also the function and parameters. Then And and Or rules could work better.
-
OK, I fixed it. Because it was such a minor update I just changed the file version to 2.1.9.1 and replaced the existing SGDK219.zip file with the new one. I fixed the problem of counting to the wrong line and the problem of only finding the rule based on the rule name, so now it will find the rule based on rule name and the function and and all parameter values.