I have an app I’ve been working on off and on for years. It’s a DND virtual table top; basically just a vector based drawing app with a (theoretically) infinite drawing space. It’s currently in C# with all drawing done in a picturebox with GDI+. Various drawing types are handled through different objects, from DND Circle objects to doors, freehand, and image icons.
I’m starting to use full-color maps as backgrounds, and GDI+ is just too slow, and I don’t want to reinvent the wheel trying to get it faster. I was originally thinking about just switching to DirectX or OpenGL and doing everything myself, but If I can find a drop-in game engine, that would save me a lot of trouble.
I would like to have something with enough flexibility that I can do these full color maps, including lighting and various blending effects, in the app. Start with a plain base and add lights, furniture, character sprites or whatever and be able to manipulate them during the game instead of having to prerender them all and just use them as background.
I also want to change as little as possible at first, so I would preferably need to be able to point it to the picture box so that I can maintain my (admittedly crappy) toolbars and other UI for now. And I would like it to start as top-down 2d but hopefully be able to eventually expand to isometric 3d and possibly even true third or first-person 3d with just a camera change within the same engine.
Any suggestions?
1 Like
I use fantasy grounds for my online D&D gaming needs, but if you’re wanting to create your own then maybe look into Unity. It’s mostly for 3d games but can easily handle 2d
I have “worlds largest dungeon” and other maps already in this one. We also game out in the boonies where internet charges are pretty high, so we can’t use anything online. The last time I looked at Fantasy Grounds it was online only, but I don’t know if it still is. Plus, free is always good, and I want to learn some graphics engine anyway. Who knows, if I can get it working and get the code cleaned up, maybe I can put it out on Sourceforge or something and have someone else keep it up to date.
1 Like
The problem with Unity, if I remember correctly, is that you are designing and writing code in the Unity IDE, and that code can be written using c#. In my case, I have a fully working app with draw code and everything already written. If I start with unity, I’ll basically be starting from scratch. I just want to get an engine that can take over my picture box as its rendering window and then I modify my draw code to add game engine assets instead of GDI+ drawing calls.
I suggest writing some tests to determine if GDI+ is the source of your “too slowness”.
When you are absolutely certain that GDI is your source “of too slowness” then I suggest:
- OpenGL over DirectX for speed,
- DirectX over OpenGL for a clean API.
Note: These opinions were formed 3 years ago when I had to research these topics for work. Things may/may not have changed since then .
1 Like
I’m absolutely certain that it’s a major portion of the slowness. The maps for “world’s largest dungeon” contain thousands of objects. Now, part of that slowness is going to be me parsing through those objects to determine which ones to actually draw at each frame as the user drags the map around or zooms in and out or whatever, but that’s not as slow as me trying to draw every object. Most of those objects are really simply lines, but it’s still possible that I’m not using the most optimized ways to do graphics paths and such and draw them out.
But it is perfectly acceptable for smaller maps, until I try to add one of these full-color backgrounds that is 5000px across. I don’t know that even directx or opengl will be able to handle that size. I’m hoping they can handle a lot more if I break it into 256x256 textures or something, but since I’m having to handle each frame manually with gdi+, even when trying to draw just the parts of the image that are on screen, it is way too slow to be enjoyable. I’m hoping that with a graphics engine, or better yet a full game engine, I can hand that off to engine developers, the guys that are supposed to know how to optimize it. The same thing goes for the 1000’s of simple objects; I’m hoping I can just shove them all into the engine and let the engine deal with figuring out what it needs to draw or doesn’t need to draw in an optimized way.
Unity uses C# and you don’t have to edit the code in their editor. The code does however have to fit into their framework for the rest of the engine. It’s your call as to how much work this would require. I don’t use Unity often (99% of the time I use Unreal Engine). If you’re just looking for a generic 3D graphics framework that works with C# (rather than a complete game engine) have a look at the OpenGL bindings page.
https://www.khronos.org/opengl/wiki/Language_bindings#C.23
1 Like
So, let me list out pros and cons so far, and let me know where I’m wrong. I’ve been doing back-end finance programming for the last 17 years, so the only graphics experience I really have is this app and one particle engine I wrote to try out openGL in c#. Everything else was screen savers written in vb3 or something. So it’s definitely possible that I’m making assumptions that are completely wrong and that I’m not asking the right questions.
Unity:
Pros: Has everything I need and I can offload physics and lighting calculations (lighting being my main concern, since I don’t anticipate a need for physics for a long time) to the engine.
Cons: I have to start from scratch with the app since I will be tossing out all of my toolbars, window management, file management, etc.
Unreal:
Pros: Sounds cool and professional
Cons: I know absolutely nothing about its capabilities, including how many systems the engine will take over vs how many I have to code.
DirectX:
Pros: Can work within my existing framework and display in my existing forms.
Cons: Simply a graphics engine, I’ll have to code my own static/dynamic lighting engines, physics engines, or anything else. (This doesn’t sound right as I type it, but it’s one of the subconscious cons I’ve had rattling around in my head. When I consider it, I don’t think I can just add a “light” object and set flags on other meshes to say they cast or receive shadows and then move the light around, but maybe I can.)
OpenGL:
Pros: Same as DirectX. Less microsoft-oriented. Seems more professional.
Cons: Same as directX.
I’ve always been big on reinventing the wheel, and I’m trying to get away from it (obviously not to the point that I’m not writing an app that already has 50 better competitors). So if I don’t have to write lighting code on my own, I would love that. Honestly, everything else I do in this app right now should be simple in directx or opengl. But since I wrote this thing, my players have started playing table-top dnd like its a video game. They insist that I zoom out and let them see the entire map so that they can see if there’s any room they may have missed on this level before they go to the next one. I’ve been fighting it by leaving large open areas with dead ends leading toward them, or long straight corridors with no doors, so that they waste a bunch of time looking for rooms. But what I want to do is give them a torch and let it light whatever it is going to light. I think that, combined with these colored maps instead of the dry-erase-marker style maps will both get them more immersed and give me a better excuse for not showing showing them the entire map.
Looking over the options some more on the internet, maybe opengl/directx do take over the lighting for me, but I still run into posts about people calculating shadow maps and such. Is it just that the graphics engines will do all of that work, you just have to be explicit to tell them to do it? And is that any different than what I would have to do with a full game engine? Or is it simply that I’m skimming tutorials and how-to’s without a proper base to work on and don’t really know what’s going on?
I’m honestly thinking now that, as much as I don’t want to, unreal or unity are probably the best way to go. I do like c++, so I suppose I’ll start working with unreal. With no real knowledge at all, it seems to have a higher “up” potential if I ever start getting into really high-end graphics or something. Any suggestions for tutorial sites that you’ve seen that are good for basics, out of the hundreds that google spits out?
So in this case, the switch from DirectX to OpenGL, or from GDI to either of these is going to be nominal compared to the overhead involved in displaying 25 million pixels. (assuming 3 bytes for rgb that’s roughly 75M of storage ), If you switch from int8 to something like float 64(accidentally) then you’re going to be paying half a Gigabyte for it.
A patient person considers creating a light-weight equivalent to WMS that handles loading/storing/caching of map tiles. If you believe that this is too much work, then consider a tile-based map
Alternatively. You can load references to a few preset tile textures and store them in a dictionary. This decreases the memory overhead of having to own, load and manage every 16x16px block’s image, to just storing a references to a handful of tiles.
If you have the desire to move to 3d in the future with a camera change in the future it might be worth it to bite the bullet and move to a more fully featured engine/framework now.
The way to do this back when I was messing with C# was to use XNA, unfortunately that appears to be dead now, http://community.monogame.net/ is what was suggested as far as I can see to stay with XNA type stream. Unity is indeed very popular and well supported, and has a reasonable license structure. I can’t say anything against Unreal engine either. I am currently loving LibGDX and JME3 engines myself.
Nominal maybe for the image background displays. But not for the maps like World’s Largest Dungeon. It doesn’t use backgrounds, because the app can’t handle backgrounds that big. Instead, it has 1000’s of vector based drawing objects that are just outlines (lines, circles, squares) and a few small (100x100 pixel) image sprites scattered around for monsters and players, with no more than 10 of those ever being on screen at the same time usually. I can’t believe that opengl or directx wouldn’t do a massively better job at optimizing the display of those objects.
As to the backgrounds, some sort of tiling engine is where I was headed, and trying to avoid, at least with me writing it from scratch. But I would like to get a lot further than just breaking my existing backgrounds into tiles and optimizing their display. I’d like to eventually get to the point that I am using the tiles and textures just as if I was creating the background in gimp. Multiple overlapped tiles with masks to determine which tiles are actually displayed at any given point, so that the user can draw out the roads, boundaries between grass and rock, etc. And add additional blending effects to support lighting and such. In most maps, the lights would be static, and the players may be carrying around one or two torches that are dynamic. But one of the current maps I have is a room in “The Age of Worms” where 7 colored lights actually become part of the puzzle. The players could, in theory, move those lights wherever they want, turn any combination of them on and off, etc. Right now, I’ve got something like 35 layers stacked and blended, to the point that Gimp wasn’t able to actually handle it. I had to pull the gimp image processing code and then write my own command line tool to work on just 2 or 3 layers at a time. I saved each layer as an image and now I can run the command line tool with a switch for the presence of each colored lamp, whether the lamp is on or off, and the presence or absence of a few special effects that the players may activate. I want to get to the point that I could do that in the app instead of having to do it outside, and actually end up with smaller files. I’m hoping that with directx or opengl, I can do it with a handful of 3d objects (walls, doors, maybe a fountain), a few smaller tileable textures (rock, dirt, water, grass, fog, etc) on top of “ground” triangles, add a fuzzy-bordered transparency mask of some sort on the triangles where they overlap, and let the engine do most of the optimization and calculate the shadows and such. But I’m making assumptions based on things I don’t necessarily understand, so maybe that would be just as much work as just coding it and optimizing it in gdi+.