Scrolling Game Development Kit Forum
SGDK Version 2 => General Discussion => Topic started by: v6v on 2012-10-19, 01:08:58 AM
-
Would it be a burden to ask:
If SGDK2 could feature sublists for managing Graphics and Framesets? Instead of all Graphics and Framesets falling under "Graphic Sheets" and "Framesets"?
That way I could create a category under Graphics Sheets called "Car Graphics"
Create all Graphic sheets of a certain type inside of it
And collapse/expand it whenever necessary without having to collapse the Graphics Sheets listing?
It helps things become organized when you have a a large amount of graphics.
-
I think Vincent had the same request because he had a lot of graphics in LoK Revival too. Vincent, did you find a good way to deal with this concern, or just push through the difficulty without any better answer?
-
Since SGDK2 Projects use an XML Structure, wouldn't it just be creating new categories for graphics to fall under?
It might call for a new version of SGDK2 and perhaps a converter for old projects...
I'm in desperate need of this. There are too many graphics and framesets everywhere. Maybe even an extension for sprites so I can categorize those too in the directory.
-
Implementing the data structure is the easy part. Implementing all the management of categories and user interactions with folders would be the hard part. But what if it were simply implemented as an extension of the name? For example, if you include a "\" in the name, everything before the "\" would represent a folder into which the object would be nested. And perhaps multiple "\" characters could be used in the name to nest objects multiple levels. Would that be a useful implementation of this idea without even requiring any upgrade or data structure change? The nesting of an object could be changed with a simple rename.
-
But when I expand the graphics sheets directory, all of the sheets would expand, regardless of how I named them.
I need a solution that would allow me to create folders under the GraphicsSheet and Frameset or Sprite folders.
This is more of an issue within the IDE. I need things to be organized within the IDE.
Sorry if I'm misunderstanding you.
-
No, I'm saying if I changed the code to interpret "\" as a folder name, then there could be real folders there instead of everything at the same level. Would that suffice?
-
Hi guys, sorry if I'm late. Yeah, I remember I asked for something like this a while back but I didn't do anything about it finally. I think a just tried to name my elements in a logical way with some meaningful letters or words at the beginning of each graphic sheet or frameset. But I understand that I have a lot less graphic sheets and frameset in LoK:R than there is in #Sharp's project.
I think that making folders with a "\" prefix is a great idea! :)
-
Thinking about this more, I'm starting to worry that you might hit some unexpected limit if you have so many graphics. Assume I make some estimates:
1. I expect the average graphic sheet to be about 160x160 pixels (25600 pixels or 102240 bytes)
2. I expect the largest number of graphics sheets that is manageable in a flat list is about 200.
3. 200 * 102240 = 20,480,000 bytes
Okay, most video cards these days have more than 20 MB of video memory, so were probably OK at these estimates. But how much over these numbers are you going? SGDK2 doesn't do much to manage memory if you have a lot of graphics. I don't know what happens if you try to use more graphics than your video memory will allow. Is it time to take a moment to do some math to see what limits you might be approaching?
-
Don't tell me that SGDK2 loads every graphic into memory, even the ones that I'm NOT currently using...
I don't load many graphics in my game at any given time, BUT I DO have a large amount of graphics (113 I believe) and as a matter of fact, I believed that that was the reason why I kept reaching "OutOfMemory" Exceptions whenever building my project (UNTIL I removed a large amoung of large Mp3 and Wav files and some Large Maps)
That's the only limit I've ever reached. And ever since I've cleaned my game from 60MB to 30MB I haven't ran into the limit again.
It's well under 200 sheets but each sheet is well above 160 by 160 pixels.
But again, I don't load many graphics at one time and I properly dispose of graphics that I load myself (2048 x 2048 For skydome texturing, etc)
How will graphics that I'm not currently using affect video memory?
EDIT:
Ohey I ran into a System.OutOfMemoryException.
But I've noticed that it only happens if I have a few things loaded within the SGDK2 IDE, such as the Map editor, Sprite Editor, etc...
I'll have to close all of the windows in SGDK2 before I compile.
-
At runtime, the game only loads into video memory the graphics that are referenced by the sprites and tiles on the current map. But I believe it leaves to the .NET garbage collector the decision on when to unload them (unless you explicitly unload them, as I guess you do with your sky). And regardless of whether the graphics are loaded into video memory , they are embedded in the EXE. So I'm not very familiar with Windows architecture, but it it loads the whole EXE into memory then it has all the graphics loaded as soon as the EXE starts, at least in compressed form. The same is true of the IDE since it keeps the data from the SGDK2 file in memory as you're working on your project.
But usually video memory is what you have to be concerned about. I would have to do a lot more investigating to see if there is a real risk. But if you can estimate how much memory your graphics take up in uncompressed format, it might make such investigation unnecessary.
-
But it is possible to create an organized structure for objects such as Sprites, Graphic Sheets, and Frame Sets, right?
Video Memory shouldn't be much of an issue for me. I don't load many images and I explicitly manage the unloading of textures on Map Changes.
-
I will try implementing the ability to nest objects in folders by including "\" in names if you think that will be an adequate solution.
-
Thank you bluemonkmn. ;D I'll try and report any serious issues I have with limitations in SGDK2 from this point on.
The college I'm at right now has computers with more Ram, 64bit Windows Installations.
I might have to start developing on those (They're much faster by the way)
-
OK, #Sharp, I think I have Framesets supporting folder names. Are Graphic Sheets the only other object you think needs to support folder names? Can you rank any other objects that you think should support folder names in order of the importance of this feature? When I get something ready I'd like to send it to you to test before releasing.
Edit: As I think about it more, I realize if I'm going to do this, I should make sure I get it right the first time. So here's a question: is it ideal to have the folder structure be part of the name, and require that the full path be used whenever referring to a frameset or graphic sheet (including in code), and allow the same name to be used so long as it is in different folders? Or is it better to make the path separate from the name, and show only the name everywhere else besides the project tree, and require that the name be globally unique independent of its folder path?
-
The first option only being a minor setback as I'd have to include the directory name in all custom implementations of GetTextureRef()
That's the only bad thing I can honestly think of.
Keep them globally unique. *This is only my opinion*
Because it would keep things incredibly simple.
For my needs I only need a structure of organization that's mainly just visual; the ability to condense and expand subdirectories of game objects is all I really need.
(Plus it would be less work for you and I because you'd have to change all of the base objects and I would have to change all of the plans XD)
In Order (This is the final list I've settled on):
Graphic Sheets
FrameSets
Custom Code Objects
Sprite Definitions
Counters
Maps (Optional, I already categorize maps by adding an A and B to the beginning of their name, because I have 2 kinds of maps)
Thanks!
-
I would also vote for globally unique names regardless of the path leading up to them. As #Sharp mentioned, it would make things simpler. Then some day, you may be able to make a change to the program to include a proper UI and data structure change so that the names don't actually include slashes, and everything will still work correctly.
-
I suspected that the globally unique name thing would be preferred. I am going to try to do this properly by adding a "Folder Path" field to the appropriate screens and leave the name itself pretty much untouched. As it turns out, trying to hack the path into the name is probably going to make at least as much of a mess as adding a new field for the folder path. And this is the kind of thing that would be harder to fix later than now, so I decided I should do it properly now rather than later. Keeping the path separate will be cleaner anyway, I think.
-
Could you test the new version for me before I release it?
http://sgdk2.enigmadream.com/ben/SGDK2IDE.zip (http://sgdk2.enigmadream.com/ben/SGDK2IDE.zip)
I think the EXE is all you need. Let me know if you have any problems. Please backup your project and SGDK2IDE.exe file before using the new/test version.
Every object for which you requested folders supports them in this version. Source Code is a little hard to figure out. There's a new "Specify Folder Name" menu item in the File menu when you're editing a source code object.
-
I happened to find everything without any issue. The directories run fine.
This is definitely worthy of a new SGDK2 version.
It runs fine for me. Thank you bluemonkmn. This really helps development!!
Continuing on now..
EDIT: Should the Clickonce installer feature this?
-
Yes, whenever I release now, both the ClickOnce installer and the formal release on SourceForge will be updated. I may not have time to release tonight, but hopefully in the next day or two.
-
If a folder is created with the same name of an existing graphics sheet the graphics sheet becomes a subdirectory of the graphic sheet and the graphic sheet itself becomes a directory.
Not a serious issue (Not even an issue at all) It actually allows for the creation of subdirectories within directories.
-
Weird. I mean surprising that it all worked out without errors, and I hadn't even planned it that way. Do you think I should keep that behavior or force a folder name to be an actual folder instead of allowing the nesting of objects within non-folders?
-
In my honest opinion I think you should keep it.
But offer a disclaimer.
Because once it's done, it can't be undone.
-
Ew, I should fix that part... that part didn't quite "all work out without errors" then. I think I can figure something out, though. Thanks for reporting in!
-
All fixed and posted. I also updated the help file and version in the official release.
-
Minor Bug!
Click the About button and close the about window twice.
-
I don't see any problem. I assume you're talking about the "About" menu item in the Help menu (there's no "About button"). It's working fine as far as I can tell.
-
My computer only then.
If that's the case, then don't worry about it.
It throws a system32 error and shows a bunch red boxes and wireframe in the form where things should be.
Sorry for wasting your time!
-
It'd be nice to find the source of the problem -- it's rarely just 1 system that will see a problem. Are there any other things going on? Do you just start SGDK2 and do that right away after the splash screen goes away? Is there any way to can do that without the error happening? Do you have another system where you can try the same thing? Are you maybe opening or closing the window in an unusual way (Alt-F4? "X" button? Enter key?) or under unusual circumstances?
-
The error happenned when I had opened an About Form in another SGDK2 version and attempted to open it in this version while the other About Form was already displaying it.
I'm looking more into this because I've removed all other versions of SGDK2 shortly after that happenned.
-
If causing the problem requires you to have 2 versions of SGDK2 installed, it's probably obscure enough not to worry about it if you can't reproduce the problem easily. But if you can reproduce the problem on just one instance of SGDK2, I'd like to know how if there's some trick to it.
-
I'm having issues bulding my project.
I need to include the .DLL files that my project uses in the same directory as SGDK2 2.2.9
But with a ClickOnce reference I can't really find it.
(I've been using the SGDK2 version that didn't use ClickOnce because of this problem)
Where can I find the SGDK2 directory now?
-
The first line in the "Loaded Modules" box in the about dialog tells you the full path of SGDK2IDE.exe.
-
I was afraid to use that path because it had a large amount of gobblety goop in the path.
(http://i50.tinypic.com/20uz9g1.png)
This arose.
The error I mentioned before.
Maybe it's related to the OutofMemoryException.
Either way it happens randomly and not at will, but once it happens it persists until I restart the IDE
-
I suspect it is related to memory based on what I'm seeing. It looks like it failed to load all the graphics and controls that use different fonts that haven't been pre-rendered in memory yet maybe. When you get this behavior, can you look in task manager and see how much memory the SGDK2IDE process is using?