Picasso

Take an image that represents the entire background for a map and use it as a tileset? Aren't there limits on tileset size? If this is possible, what about having a different background for each map? Would that eat up all your tilesets or can you have an unlimited number of tilesets?

Thanks for the input. I'll give a review after I've had a chance to look at each build.

I'm sure it would require some coding, but would it be possible to use an image as the background for a map? It could be set as the initial layer or whatever. I looked at RenderTexture and thought it might be possible to pull it off with some tweaking. Any ideas/suggestions/flames? I looked the forums and didn't find anything like this, which I think is pretty surprising.

It's been a while since I've worked on EO, and I've decided to start a new project. There's some nice changes and builds available to start with, but I'd like some opinions from those that have used the latest & greatest builds. Yes, please don't flame on and say I should try them all. I probably will, but just asking for a suggestion one way or the other.

Nice, Robin…very nice.

Considering the relatively small codebase of CS:DE, as well as the requirement for rapid GUI refresh, moving to an OO design can be argued against. However, if the requirement for speed can be maintained, I believe OO design has considerably more pros than cons. I don't suggest moving all code into objects and strictly working within a rigid OO framework. In moving the GUI frames to objects, I've removed some of the most convoluted code sections in CS:DE, allowing for easier maintenance, feature development, and debugging. Please don't take that as a slight on CS:DE code, because I strictly mean "convoluted: Extremely complex and difficult to follow". As of now, that's the only code that I plan to move. Speed was a significant concern as I made the conversion. To confirm that the classes weren't going to kill the refresh, I created a map with dozens of NPCs and performed a test after every frame was moved to its own class. Even running through the IDE, I never had a pause or stutter in the movement. While that may not be a complete test case, it's certainly a test of refreshing with a fair amount of processing.

I've written in CP/M Basic, ObjectPascal (Paradox/Delphi), and C#. I found out about EO because my son and I want to make an mmorpg. He's 9 and certainly not too young to start learning code. I searched extensively for a system that was flexible, complete, and relatively simple to understand. I spent 2-3 weeks wrapping my brain around EO, manually adding in multiple tutorials to familiarize myself with the code. Then, I found CS:DE, which is faster and has a much cleaner GUI. I spent a couple weeks on learning it, then decided to restructure the code if I was going to spend an extended amount of time with it. Having the code restructured in this manner allows for easier maintenance as well as allowing more junior coders to understand and work on the code.

Thanks for the feedback Robin. Classes in VB6 are terrible? LOL…holy crap, YES! However, having separate classes that handle their own mouse events and drawing makes it all easier to wrap my brain around. For example, each frame class has Draw, Mouse_Down, and Mouse_Up methods that are called from modDirectX8 or modInput that handle only their drawing and mouse methods. The idea is separation of concerns. The be honest, the main reason to mod the code in this way was to make it easier for me to work on. It's like taking apart a carburetor and laying out all the pieces to understand the inner workings before making modifications. The purpose in sharing this is to get feedback and to see if there's an interest in the EO community for an easier to understand codebase of CS:DE. Of course "easier to understand" may be more indicative of a personal problem. ;-)

The quick summary is that I added a class structure to CS:DE to make it OO. The main goal was to make CS:DE easier to work on using OO practices, especially the GUI. When I started working with the CS:DE code, I realized the biggest learning curve was how to handle the graphics, buttons, mouseclicks, etc. I created a couple new classes that encapsulate the functionality for frames or windows in the GUI. For example, there is a frame for the main menu that has sub-frames for news, login, credits, register, class selection, and character name & sprite. By encapsulating these frames and defining the functionality for each individually it's easier to manage them from a code perspective as well as modify existing or add new frames easily. The screenshot is of my IDE with the code for the main menu frame open. The main thing to notice here is the list of classes on the right. All code has been modified and the client runs great. There's some cleanup that needs done…a few straggler methods that probably need to be yanked from their peaceful existence and moved to one of the frame classes. If anyone is seriously interested, I can make the code available, but please understand that the code is not for the newb or faint-hearted, as Robin has pointed out many times in reference to CS:DE. While these code changes may be easier to work with, they're still more complex than EO. By the way, and I can't say this enough, Robin and his merry band of cohorts deserve grand kudos for their work and time on EO, CS:DE, support, etc. >!