64-Bit Version + Optimization for Highend machines?

[L.C.]

1. Are there any plans for a 64-bit version?

 

2. Are GPUs currently used to do most of the work in DCME?

 

3. Do you plan to have the grid thing rendered in 2D OpenGL? (For that matter, how is it currently rendered?)

 

4. Will there be a feature to define how much memory DCME should use for work?

 

5. Will DCME have multiplayer-mapping support (like remote !@#$%^&*istance, but allowing multiple mappers to connect together and work on the same LVL file)?

 

6. Are there any plans to have built-in tools (or perhaps "addons") for things like ship rotating, skin editting (for the Continuum menu), audio conversion (to convert audio files to wave), settings editor (with realtime/dynamic previewing), a "zone repository", Subgame/!@#$%^&*S configuration wizard, etc?

 

7. (Zone repository would be like, something that can help someone or a group of people to develop a zone and have it organized and compiled by the program so that to take the thing live or to testing groups, all that would have to be done is a simple "copy-and-paste".)

 

8. Have there been any considerations about changing the name "Drake's Continuum Map Editor" to something a little more broad (like "Drake's Continuum Editor" or "Drake's Tools" or "Subcraft" for example)?

 

 

Some of my questions are stupid, and it has been a while since I've been around DCME.

[Drake7707]

1. vb6 was designed for 16/32 bit systems, so no

 

2. not at all, it uses standard user32.dll api functions

 

3. directx would be better than opengl because of the better support and integration in vb6.

 

4. i don't know if that's possible in vb6

 

5. i've thought and considered it. But i want to know how many ppl will actually use it because it's a pretty hefty block to code

 

6. making DCME a suit of tools is not really the goal (it would become too bloated), but it might once become part of such a suit (though unlikely to happen). Though a settings editor would be pretty nifty with the Test Map functionality already in place. In fact it could be directly copied from FACTS which is written in vb6, and i had the source code of it here somewhere (i don't know if i still have it)

 

7. Like a zone management system ? Not in DCME, maybe in some sort of collection of tools

 

8. I've thought about removing my name from DCME yeah , because DCME was a quick & dirty project name when i started working on it, and i never knew it would grow to be so big as it is now

[Samapico]

1. Can't do anything about 64bits with VB6, as far as I know

 

2. I don't think so, we use pretty much only gdi32 API's

 

3. The grid is currently drawn using the built-in function of the picturebox control, nothing special.

 

4. uh, not sure what you mean by that; so far pretty much the only thing that is variable in memory usage is the number of maps opened.

 

5. That would be cool... indeed... but I don't really want to get into that :/

 

6. Settings editor were part of the plan, and with the Test Map tool, it's pretty much realtime. I also had several graphic tools in mind, such as the ship rotator you speak of. The current Tile Editor will eventually be 1-Fixed 2-Expanded to a generic 'Image Editor' 3-Pimped

 

7. Could be interesting... but would most likely be an external program (that could start DCME to edit maps, of course)

 

So yeah, maybe settings editor could be external as well

The DCME exe is already pretty huge, we'll have to stop adding stuff to it

!@#$%^&*, even the testmap could be an external app... could be more efficient, and would lighten up the DCME exe

 

8. If we do make all these external tools, then we'd have to give a name to the set of tools, but the map editor itself would stay DCME, and could be run independently I guess

 

lol, ok let's compare our answers...

[Samapico]

And a word about optimization for high end machines... We're trying to optimize it for low end machines, so high end machines will just run it even better

It's not like there are many things to adjust performance-wise. Some parts of the code, however, will be OS-specific, since some API's only apply to XP and later, like AlphaBlt. Regions will probably use that API to colorize areas, instead of the current way that gets very ugly when a few regions are on top of each other.

[L.C.]

Perhaps you (Samapico) and Drake should start thinking about producing a 'suit' (Subsuit ["Sub-suit"] or Subsuite ["Sub-sweet"] or Drake Suit/e ["Drake Suit/Sweet"] ), sort of like how Nero and Adobe have their products branched out.

 

Could strip some feature of DCME and turn them into individual/separate processes or applications to increase efficiency.

 

Either Subsuit or Subsuite in my opinion would be a good name for the whole kit.

- Map Editor

- Tile Editor

- Settings Editor

- Skin Editor

- Banner Editor (although sort of useless since Cont has a built-in, you could probably clone Cont's skin editor GUI just for the sake of having this in the kit)

- Ship Editor (graphics / rotating)

- Zone Tester (quick 'n' dirty way of testing your settings, map, ship rotation, banner and possibly skin)

[Samapico]

Plus, it could be easier to get other people to help on some parts. Some components could even be done in something else than VB, I guess.

 

I don't know about skin editor though :/ It can't really be linked to any other item of the suite. Maybe except the image editor. If someone wants to make one, and wants it to be part of the suite, I'm fine with that. But I doubt me or Drake will make one. But a WYSIWYG skin editor sure would be nice. And surely not very complicated.

That, and a F1 menu editor

 

The banner editor would simply be the image editor, with fixed size and color depth

[»doc flabby]

I don't know about skin editor though :/ It can't really be linked to any other item of the suite. Maybe except the image editor. If someone wants to make one, and wants it to be part of the suite, I'm fine with that. But I doubt me or Drake will make one. But a WYSIWYG skin editor sure would be nice. And surely not very complicated.

That, and a F1 menu editor

The already is a WYSIWYG skin editor.

 

http://forums.minegoboom.com/viewtopic.php?t=7156

[PoLiX]

And there was 2 even before that.

[L.C.]

The already is a WYSIWYG skin editor.

 

http://forums.minegoboom.com/viewtopic.php?t=7156

No offense or anything personal, but using that logic DCME is a complete and utter waste because SSME and several other map/tile editors existed before DCME was even started.

 

DCME is high quality, professional material (and so is SSME).

 

That skin editor isn't completely stable, lacks active development, and is obviously rough-draft quality. The GUI itself needs a ton of work (even though everything is in a GUI format, the work is at least a bit easier than doing it from scratch in notepad and Photoshop, but still has high levels of confusion). A program should help someone to learn how to do something, not just have buttons and a rough-draft quality GUI design that meets the bare-minimum to being able to produce skins.

Edited August 31, 2008 by L.C.

[RiiStar]

I've been making a cfg editor for a few years now inbetween other things written in Delphi 7...

Currently working on a multi-do!@#$%^&*ent version of it (version 2) which expands on my orginal simple one.

Sama has seen version 1, i once offered to make a vb version for DCME but it never eventuated cos of other projects etc.

Though im not the worlds best coder im sure my work could be done better, but hey...

 

As for a suit of apps, i think DCME should be the "focus app" and have some sort of plugin/addon system (or launchpad?)

for other tools that go hand in hand with arena/event development...

 

Edit: My crappy cfgEdit v2.

Please Note that this has only been developed for me, more thant likely has bugs...

And apart from me only a few others from TWDev have used it ...

Edited August 31, 2008 by RiiStar

[Samapico]

Yeah, having external apps (not plugins) that can easily communicate with DCME (receive data from a command line, like the path to a file, then send a simple message to DCME saying 'hey, I'm done with that file, update your stuff' , and DCME could update its data). Anything that would require more than that could get complicated. But with that, these other apps could be coded in anything, not necessarly VB. So, your cfgEdit could very well be part of the suite in its current form (with a few adjustments for the communication, I guess). Perhaps a small dll could be used to link the apps, so any developer could make his own app for the suite.