DCME The Next Generation

[Samapico]

As you know, DCME is coded in VB6.0, a language that has been dead for years already. If it wasn't for the hugeness of the project, we would already have switched. Drake also started this project for personal satisfaction more than anything, it never really was planned to become so popular. The upcoming issue is that after Windows 7, there probably won't be any OS that support it. So we'll need to eventually port it.

Also, with newer clients being developed with new features and such, DCME would eventually need major overhaul to adapt. The current project is quite limited, because it's already full of features and functionalities that were not planned in the beginning. The lack of class inheritance also makes some things more complicated than they should be.

I'm also currently faced with a major stability issue of a seemingly random bug that is pretty much impossible to debug...

 

So yeah, DCME will need a total recode under another language. The questions are when and how

 

Either I ...

• throw my computer out the window a couple of times trying to get the current modifications (that's a lot) working, to get nice new cool menus (they are great), just to throw it all away eventually under a totally new platform.
  
• revert to 3.4.15 source, grab all the minor bug fixes I did since then, merge them, release an update, branch to a completely new build, just fixing minor issues here and there until it is done
  

 

So... discuss... what language could be used? Which libraries could be useful? Which new features would you like if there was a completely new version? What could be improved in the general structure of the application (layout, the way tools work, etc) ?

Also, if this ever branches to a more popular language, would YOU contribute?

[Psythe]

I'm not knowledgeable on things like languages or libraries, but I'll suggest features.

 

The current DCME features are good, minus a few things overlooked (I think the shape of a circle wasn't that smart, but who uses circles anyways),

 

I'd like:

• fully-functional test map feature, but I think you said something about using discretion to test the maps? That'd be good.
  
• an option to make the tileset a separate window that can be quickly opened and closed with "T"
  
• Different sizes of autotiles (for thicker walls of 2x, 3x, 4x, etc or for small tilesets that are only corners and straights)
  
• More grid options, like how many lines
  
• Improved layout of tools
  
• Export a selection as a picture for sharing on forums as screenshots
  
• Split rotating tool into buttons for "rotate 90*", "rotate CC 90*", etc
  
• After making a selection, options to translate (as in limited to four directions, would this be necessary at all?) and resize (drag corners of selection to resize it, autotiling keeps it clean)
  

[Samapico]

[Psythe]

Ah, I didn't know some of those things

 

Uh, for a better tools layout, I was going to suggest keeping them all on the top in one line, and then a divider, and then the other features, and then a divider, and the toggleable things like grid and regions (switch that order of dividers around until it makes sense)

that way it's all in one place at the top.

[Samapico]

Found this at http://www.thinkingparallel.com/2007/03/06/c-vs-c-a-checklist-from-a-c-programmers-point-of-view/ :

Highlighted what I like particularly

 

Pro C#:

 

garbage collection

array bounds checking

huge .NET-Framework library

types have a defined size (e.g. a long is 64Bit)

strings are encoded in UTF/16

autoboxing - every type can be treated as if it inherits from object

supports constructor-chaining (one constructor can call another constructor from the same class)

when a virtual method is called in a constructor, the method in the most derived class is used

static constructors (run before the first instance of the class is created)

exceptions have access to a stack trace

advanced runtime type information and reflection

supports variadic functions nicely

built-in support for threads

no need for header files and #includes

no fall-through on switch-statements

arithmetic operations can be checked for overflow if required

objects must have a definite value before being used

attributes can be attached to classes and retrieved at runtime

no forward declarations required, classes can be arranged at will

access to class members / functions is done only by the dot (no more -> or :

conditional functions (e.g. for debugging)

structs and classes are actually different (structs are value types, have no default constructor in general cannot be derived from)

supports properties

readonly members are const, but can be changed in the constructor

finally block for exceptions

arrays are objects

support for anonymous functions

supports the base keyword for calling the overridden base class

 

 

Pro C++

 

better performance

portability

multiple inheritance

deterministic destruction (allows RAII)

any type can be thrown as exception (only classes derived from System.Exception in C#)

ability to enforce const-correctness

implicit interfaces on generics (in C#, generics must be constrained with an interface)

offers pointers (C# only offers pointers in unsafe mode)

support for macros

support for global variables, functions, constants

allows default arguments on function parameters

STL

supports bitfields

 

Where C# is just different from C++

 

value types and reference types exist (struct is value-type, class is reference-type)

value types live on the stack, reference types on the heap

references can point to null (must not be valid)

code is packaged in assemblies in C#

no automatic conversion from int to bool in C#

main-function is called Main in C#

no semicolon after a class declaration in C#

everything derives from object or can be treated as if

 

Ah, I didn't know some of those things

 

Uh, for a better tools layout, I was going to suggest keeping them all on the top in one line, and then a divider, and then the other features, and then a divider, and the toggleable things like grid and regions (switch that order of dividers around until it makes sense)

that way it's all in one place at the top.

Don't worry about toolbars and such... it will use REAL toolbars that you can move around and undock

[Bak]

You could do it in Java, and they all you need to do is build upon CLT.

[Dr Brain]

Make sure it'll run in Wine or natively on Linux.

 

Any reason to use C++ over C? The more I use C++ the more I dislike it.

 

Seriously, though, you should think of this as an opportunity to learn a new language, like Python, or Ruby (or C# if that's new to you).

[Samapico]

C++ over C ???

 

one word: classes

 

another word: inheritance

 

C# isn't new to me, worked with it a bit... Aren't python and ruby suited more for ... scripts kinds of things? I have no idea, actually, that's just the idea I have of them. I'm probably wrong

I'd prefer using something I already know well... learning a new language isn't much of a problem for me if I ever need to, but I'm just a "casual" programmer, so I don't really 'need' to right now. I'd also like to use a popular language so we can have more contributors. Also, there's always the possibility of having some modules in another language or something.

 

Oh, and:

btw you should really rebrand it if it gets written in a new language

Give ideas

[»Lynx]

Ruby is fucking sexy. I only came here to second on Dr Brain though, try to make it either platform independent or able to run (smoothly) in Wine.

 

-L

[Samapico]

Yes, cross-platform will be one of the main objectives

 

 

Edit: and also C++ has a whole lot more of libraries to use with it

[»doc flabby]

I Personally think it probably isn't worth trying to convert it away from VB. Windows 7 is going to be around, i don't think microsoft has announced anything after, alot of people suspect Windows 7 might be the "last" windows release. So Whilst I wouldn't start a new project in vb6, i think porting DCME will be such a huge task, and its such a nice editor already it might not be worth it Also part of me suspects that Continuum might not make it past windows 7 as well Edited August 30, 2009 by doc flabby

[Samapico]

The last windows release? ... pretty sure between now and 2040 another OS will come out

[CRe]

12 21 2012

[Samapico]

12 21 2012

Doh, forgot about that

[Drake7707]

C# also has a much more extensive GUI support (menu items, dockable toolbars, and all those things that are rather hard to do with subclassing in vb6). It's also much much much more stable than vb6. C++ is better for speed, but it seriously complicates things programming in it, especially if you're not used to it (which is a thing to avoid when you port something ).

 

Java graphics are sadly enough too slow, and in C# the GUI frontend could be made in silverlight, it's not that hard and you could map your map from your browser (or stand alone if you prefer) AND it is cross-platform.

[»jabjabjab]

I think we all learned that lesson when BaK did Continuum Lvl Ini Toolkit

[Hakaku]

I kind of second Doc Flabby in that it will be a huge task to port everything from DCME to another language. If you're looking towards the future, then I'd recommend trying the F# programming language, as it's already picking up support and is intended to be cross-platform. But more practically, I'd say go with C# for reasons already mentioned.

[Drake7707]

I kind of second Doc Flabby in that it will be a huge task to port everything from DCME to another language. If you're looking towards the future, then I'd recommend trying the F# programming language, as it's already picking up support and is intended to be cross-platform. But more practically, I'd say go with C# for reasons already mentioned.

 

I checked out the article on wikipedia and I find the F# language quite cryptic oO. Well hard to read anyway with all those different characters for operations and abbreviations for iterations, lists, etc.

[Kilo]

C(.*)

[Bak]

Java graphics are sadly enough too slow

 

I think we all learned that lesson when BaK did Continuum Lvl Ini Toolkit

 

CLT worked fine on my 2003 laptop. It's 5 years later so computers are 3 times faster now.

[Drake7707]

Java graphics are sadly enough too slow

 

I think we all learned that lesson when BaK did Continuum Lvl Ini Toolkit

 

CLT worked fine on my 2003 laptop. It's 5 years later so computers are 3 times faster now.

 

 

I mean I'm not adept enough in java to program the GUI in a responsive way when so many things have to be drawn. Sama & I had to use a few hacks here and there in vb6 to let it run smoothly (as in 200% speed increase hacks), I don't think I will be able to do the same in java (well technically it would be easier to use an observer pattern to let the updates & redraws of the map happen, but I'm hesitating about the impact it would have on the drawing speed)

[»doc flabby]

If you use hardware acceleration (OpenGL or DirectX), java (java3d) supports both and so does c# (opentk, XNA, SlimDX), you probably would get a huge speedup on the screen drawing whichever programming language you use. 2D graphics (Orthanganol Projection) in OpenGL for 2d graphics is pretty easy as you can set it up to measure everything in pixels. Edited September 8, 2009 by doc flabby

[Samapico]

I figured I could use Discretion not only to test the maps, but why not use its engine directly to render the map? I'd just need to make discretion modules specifically for editing the map, et voilà!

This could even lead to awesome things like online editing of a map (ideal to fix tiling errors, or even collaborative work to make maps).

 

Related topic in Discretion section:

http://www.ssforum.net/index.php?showtopic=21813&pid=258726&st=0entry258726

[aquarius]

a very useful feature would be to 'fill in' a certain element in the lvz with tile X. That way i can say images 1-5 fill with solid specail tile - and save me 3 hours

I think it would promote fancier game design.

[L.C.]

This could even lead to awesome things like online editing of a map (ideal to fix tiling errors, or even collaborative work to make maps).

lol.

 

Real-time multiplayer Subspace mapping with up to 1024 players.