Page 31 of 37

Re: Development Blah: Comments

Posted: Fri Jul 25, 2014 4:32 pm
by Sirius
I have been doing some DLE feature work over the last few weeks - the state of the bug tracker makes me think my timing is unfortunate, but I will catch up eventually. There are a couple topics I'm wondering if you have any opinions on though.

1) STL containers: use or avoid? I have a situation where a vector might be of use; while DLE has a dynamic array class, it isn't designed for situations where you want the size of the array to exactly match the number of (real) items in it, but don't know ahead of time how many there will be. The program currently doesn't use them at all, as far as I've seen; whether there's a reason for that, I'm not sure.
Some people do dislike STL containers... often for good reasons. But when they're not busy shooting you in the foot, they can be fairly useful.

2) Error handling :mrgreen:
The "C++" way to do these is exceptions, which I noticed D2X-XL uses sometimes - DLE currently doesn't though. For real "we didn't expect this!" errors like running out of memory somewhere, they can be useful and that's where I'm considering using them. I'm told they have to be used carefully to avoid spaghetti code though (especially that they shouldn't occur during typical program flow).

The "C" alternative would be storing error information in the function's return value. DLE functions do often return values, but they may or may not indicate whether an error has actually occurred. For this approach to work well, it typically needs to be systematic. Then, if you want to handle (and not ignore) the return values, there are a few options that I recall seeing:
* Nested "if"s. Quickly leads to "indentation ad absurdum".
* A running status variable - once something fails, it's set to "failed" and nothing else in the function runs
* Goto. If a failure occurs it skips to the end of the function and does cleanup.
* Multiple exit points to a function. Can be a great way to get memory leaks and other weird bugs, but if all resources that need to be released are encapsulated in classes on the stack, it might actually work. DLE doesn't do this though so I don't think it's an option for me.

Any thoughts on that? I am leaning towards exceptions, but outside managed code I don't have that much first-hand experience with them. That's OK though, something new to learn :)

Any of this basically would have to apply to new code first... DLE is quite large and things are not going to change overnight.

Re: Development Blah: Comments

Posted: Fri Jul 25, 2014 8:33 pm
by karx11erx
I don't understand your problem with DLE's dynamic array class: You can size these arrays to any size you need, and also can resize them on the fly w/o loss of information.

Exceptions should be used for what their name suggests: Exceptional ( unforeseen) situations, not standard error handling.

Re: Development Blah: Comments

Posted: Sat Jul 26, 2014 6:47 pm
by Sirius
They are usable, but there are a couple problems I'd probably need to address.

First one is that every time you resize the array, it basically allocates new space, copies the contents, and deletes the old space. That means you probably don't want to resize it before adding every single item - if you're adding 300 decently-sized data structures to an array that way there's going to be a lot of overhead. It is possible to figure out how many items need to be added beforehand, though, so that's what I'm working with for now. I imagine a more flexible implementation might use a buffer with spare space left over, and only resize it every 2^n items - but I'll worry about that when I need it.

The bigger problem is that it doesn't handle datatypes containing classes very well - specifically because during the initialization, it memsets a "nil" copy of that datatype to zero. I had a datatype containing a CString and it basically meant the program crashed when the dynamic array was destroyed. I don't think the memset is strictly necessary - I'll need to check more closely what "nil" is being used for to make sure any workaround I implement is actually safe though. I suspect it's used to check for unpopulated items in the array, and if so there may be ways to do that that don't risk memory corruption if used with classes.

It does feel an awful lot like reimplementing std::vector though :mrgreen:

Re: Development Blah: Comments

Posted: Mon Jul 28, 2014 7:43 am
by karx11erx
Well, you can derive a more specialized or flexible class from it.

Re: Development Blah: Comments

Posted: Wed Jul 30, 2014 8:08 am
by Sirius
Yep, definitely an option. I'm also experimenting with MFC's CArray class to see whether it will work for my case.

It's slow going either way, though... this (it is basically a full POG editor) must probably be the single biggest addition I've worked on for DLE, and requires a lot of new code, a lot of code changes so it feels natural and not hacked-in, and then a lot of testing so I don't cause Armageddon :mrgreen:

Re: Development Blah: Comments

Posted: Sat Aug 02, 2014 3:31 pm
by karx11erx
Hoe about using my CStack class? It allows to resize the underlying array in bigger chunks. Use CStack::SetGrowth() to set the chunk size. It also has a ToS() function telling you how many elements it actually contains.

Re: Development Blah: Comments

Posted: Thu Aug 21, 2014 11:43 am
by Weyrman
1.17.75 working great. My game picked up at the savegame and I played on with no issue. I like the now visible lightning effect on the Weyrman Effect, it looks great!

Thanks for your ongoing effort.

Re: Development Blah: Comments

Posted: Sat Aug 30, 2014 3:32 am
by Sirius
I remember trying to create new menus while experimenting with D1DJGPP. Ugh-ly.

Didn't help that I was pretty new to programming back then (2000 or 2001 I think).

Re: Development Blah: Comments

Posted: Sat Aug 30, 2014 9:22 am
by karx11erx
I think that the general menu management in D2X-XL is acceptably transparent and expandable since my rewrite a couple of years ago.

This time I only cleaned up the menu manager's input handling function.

Re: Development Blah: Comments

Posted: Sun Oct 05, 2014 9:23 pm
by darklord42
Out of curiosity, Is the mac version actually being updated? when I click on the download it is still .83 despite the name of the link.

Re: Development Blah: Comments

Posted: Sun Oct 05, 2014 11:52 pm
by karx11erx
The OS X version's version number was erroneously incremented on the web page. The OS X version (unfortunately) doesn't get updated very often.

Re: Development Blah: Comments

Posted: Tue Nov 18, 2014 12:31 pm
by bloort
You guys are all deranged and mad! A HD version of D1 and 2? Cudos to everyone involved. This is beyond amazing, and I'm loving every minute of it. I am simly _amazed_ beyond belief every time I fire this up. Who could have imagined this? Will this work on my 486dx66 hehehehe. 10 000 camels worth of thank you's for all the effort.

I'm breathless looking at this work of art and science.

amazed.

Re: Development Blah: Comments

Posted: Tue Nov 18, 2014 4:07 pm
by karx11erx
You are welcome. :)

Re: Development Blah: Comments

Posted: Sat Nov 22, 2014 3:23 am
by bloort
This is so much fun. I just had a thought. I wondeer if in D2, on the last level there is a switch that was broken. you had to guide a missle through the mesh, and then down a long curved tunnel to hit the switch...I imagine that was supposed to open the wall, but that didn't work in the original D2. I'm curious to learn if anyone ever noticed, or fixed the switch?

Re: Development Blah: Comments

Posted: Sat Nov 22, 2014 9:50 pm
by karx11erx
Why don't you try it and let me know? If it doesn't work with D2X-XL, I will take a look into it. Might be a flaw in the level's design though (trigger not properly linked to door / wall); In that case, the level would need to be fixed rather than the program.