Development Blah: Comments

All other topics around Descent and D2X-XL

Moderators: Frustikus, simX, Aus-RED-5

Sirius
Posts: 1987
Joined: Tue Sep 25, 2007 10:29 pm
Location: Bellevue, WA
Contact:

Re: Development Blah: Comments

Postby Sirius » Fri Jul 25, 2014 4:32 pm

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.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah: Comments

Postby karx11erx » Fri Jul 25, 2014 8:33 pm

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.
Sirius
Posts: 1987
Joined: Tue Sep 25, 2007 10:29 pm
Location: Bellevue, WA
Contact:

Re: Development Blah: Comments

Postby Sirius » Sat Jul 26, 2014 6:47 pm

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:
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah: Comments

Postby karx11erx » Mon Jul 28, 2014 7:43 am

Well, you can derive a more specialized or flexible class from it.
Sirius
Posts: 1987
Joined: Tue Sep 25, 2007 10:29 pm
Location: Bellevue, WA
Contact:

Re: Development Blah: Comments

Postby Sirius » Wed Jul 30, 2014 8:08 am

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:
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah: Comments

Postby karx11erx » Sat Aug 02, 2014 3:31 pm

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.
User avatar
Weyrman
D2X-XL Expert
D2X-XL Expert
Posts: 579
Joined: Tue Sep 25, 2007 7:47 pm
Location: Brisbane Australia
Contact:

Re: Development Blah: Comments

Postby Weyrman » Thu Aug 21, 2014 11:43 am

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.
-SYSTEM SPECS-
MBoard:"GigaByte Z68X-UD3H-B3" Motherboard
CPU: Intel i7 E2600 3.40GHz
RAM: 8GB DDR3 2133MHZ
HD: WDC 10EARX 1TB SATA
Video: GigaByte 1G ATI 4890
Monitor: Asus VS428 LCD 24"
Sound: Onboard - now with connected 5.1 sound system
OS: Windows 7 x64 Home Premium
Sirius
Posts: 1987
Joined: Tue Sep 25, 2007 10:29 pm
Location: Bellevue, WA
Contact:

Re: Development Blah: Comments

Postby Sirius » Sat Aug 30, 2014 3:32 am

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).
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah: Comments

Postby karx11erx » Sat Aug 30, 2014 9:22 am

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.
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: Development Blah: Comments

Postby darklord42 » Sun Oct 05, 2014 9:23 pm

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.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah: Comments

Postby karx11erx » Sun Oct 05, 2014 11:52 pm

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.
bloort
Posts: 10
Joined: Tue Nov 18, 2014 12:22 pm

Re: Development Blah: Comments

Postby bloort » Tue Nov 18, 2014 12:31 pm

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.
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah: Comments

Postby karx11erx » Tue Nov 18, 2014 4:07 pm

You are welcome. :)
bloort
Posts: 10
Joined: Tue Nov 18, 2014 12:22 pm

Re: Development Blah: Comments

Postby bloort » Sat Nov 22, 2014 3:23 am

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?
User avatar
karx11erx
D2X-XL Master
D2X-XL Master
Posts: 8112
Joined: Mon Sep 24, 2007 8:48 pm
Location: Wilferdingen, Germany
Contact:

Re: Development Blah: Comments

Postby karx11erx » Sat Nov 22, 2014 9:50 pm

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.

Return to “General Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest