Reading another SO question it seems that DrawableGameComponents aren't the way forward. I took this upon myself to do a bit of research and using the Particle sample from the XNA Creators website, I decided to strip out the use of DrawableGameComponents. Everything compiled fine, except for the fact that I don't have DrawOrder available and the example uses this for the particles.
How can I change the DrawOrder as if I was using a DrawableGameComponent?
GameComponents are a great tool, and can make your code much easier to use and reuse. I would disregard Andrew Russell's answer from the other SO question. It is highly biased. GameComponents are fine to use. They are similar to a Singleton. You wouldn't abstain from using the Singleton pattern because somebody expressed a negative opinion for it, would you?
Trying to duplicate this functionality that already exists in the framework is just silly. Andrew Russell's opinion was that GameComponents can make your code messier. I would argue that trying to write your own layered drawing system would make your code messier.
Bottom line: Use the functionality that already exists. Don't change your coding style because somebody insulted it. You don't have to use the latest and greatest when the older style still works.
I won't tell you which approach is better, but this is how you would do it without using GameComponents:
In the game's Draw method, you call the Draw methods of the particle systems in the order you want:
smokePlumeParticles.Draw(gameTime);
explosionSmokeParticles.Draw(gameTime);
projectileTrailParticles.Draw(gameTime);
explosionParticles.Draw(gameTime);
fireParticles.Draw(gameTime);
Related
With older languages (non-OO Ex. Alpha Basic +) What is a good way to layout the code when reading threw it so your not constantly having to jump back and forth? I find myself having a hard time seeing the big picture of some programs and how there functioning, making it even harder to implement whatever change I need to make.
For procedural language, can you try few code analyzer tool. This question can be a pointer. In case you need some customized flow, a simple tool with perl/python would also help you. These tools will definitely help in ease of understanding "high" level picture of the system/subsystem.
HTH!
I am doing a design and build dissertation for my final year.
Everything is more or less good, except I cant find a software methodology to fit my process.
Basically I did the implementation FIRST and then from that I used tools to reverse engineer class diagrams, ERD, etc...
I can blag that I followed the waterfall method or something, but I would rather try to find an actual Software Development Mythology which does the implementation first.
I do know that is REALLY bad and is probably non-existing, however its small project and personal use only.
any helpful suggestions are greatly appreciated.
If you didn't design it first I don't think it will fit in any DESIGN pattern...
Most of the Design patterns are focused on designing it first, to save you the trouble of ending up with a bad software poorly designed.
You can just say you did the design you reversed engineered and followed it, assuming it fits any design pattern.
If the project is small enough to excuse doing something you say is "bad," maybe it's small enough to redo in a way that's "right." Just pick a methodology, (re)design your project according to that methodology, then re-code it according to the design. That way you wouldn't have to fudge anything.
There is no real process or software model that endorses coding before anything else. Well, technically there is the "Code-like-hell" approach but that is universally condemned (and not actually even a "real" approach in that it's considered a mistake.)
(See #27: http://www.stevemcconnell.com/rdenum.htm)
Most software models and processes exist to bring engineering principles to projects, and coding before planning is not an engineering principle. Granted, it's not necessarily wrong on an incredibly small project to just go ahead and code (most people would do it that way). At the same time, it does not follow any type of process or model that is well-established or almost universally accepted.
Your best options now are to redo it, say you reverse engineered it, or try to fudge it to fit some type of model, but I can't actually endorse doing the last one as it would probably end up just becoming lying.
Read about XP: extreme programming
http://www.extremeprogramming.org/
I have been assigned the task to refactor a Delphi unit. Wow. 10000 lines of code, no documentation, tons of copy and paste code.
THere are many methods made with copy and paste that could be refactored, anyway I am lost in all those lines, I have the interface section where I can "find my way", but in general what do yuo suggest for tackling this kind of task?
Thanks.
Get yourself a copy of Working Effectively with Legacy Code by Michael Feathers. It has all kinds of techniques for safely refactoring code to get it running under a test framework. Examples are mostly in Java and C++ but should be easy enough to figure out.
Install a third-party refactoring tool (or multiple) such as CodeRush for Delphi(sadly no longer developed), Castalia or ModelMaker Code Explorer. Delphi has some refactoring support built in but in my experience it is too limited and tends to choke on very large code bases.
Buy a copy of Simian. It doesn't have direct support for Object Pascal but its plain text parser works well enough. If enough people request support for Object Pascal I'm sure they'd add it. I haven't found any other code duplication detection tool as capable as Simian.
I would also recommend bookmarking http://www.refactoring.com/catalog/ and http://www.industriallogic.com/xp/refactoring/catalog.html.
It also wouldn't hurt to get a copy of Clean Code: A Handbook of Agile Software Craftsmanship by Robert "Uncle Bob" Martin et al. It's easy to recognize bad code. It's much harder know when you're writing good code.
A word of caution: Focus on refactoring the code you need to work on. Its easy to start down the rabbit hole and wind up spending months refactoring code that wasn't immediately relevant to the task at hand.
And save your self some trouble. Don't try to "fix" code and refactor it at the same time. Refactor first, then fix bugs or add that new feature. Remember, refactoring is modifying without changing external behavior.
Resist the urge to attempt a complete rewrite. I learned the hard way that crappy code that meets the user's requirements is preferable to clean code that doesn't. Crappy code can always be incrementally improved until its something to be proud of.
I think the best thing you can do is to write DUnit Tests for the interface. It forces you to understand the existing code, helps during debugging and it ensures that the interface acts the same after refactoring.
The Top 12 Reasons to Write Unit Tests apply perfectly in your case:
Tests Reduce Bugs in New Features.
Tests Reduce Bugs in Existing Features.
Tests Are Good Documentation.
Tests Reduce the Cost of Change.
Tests Improve Design.
Tests Allow Refactoring.
Tests Constrain Features
Tests Defend Against Other Programmers
Testing Is Fun
Testing Forces You to Slow Down and Think
Testing Makes Development Faster
Tests Reduce Fear (Fear of change, Fear of breakage, Fear of updates)
I've faced similar situations. My condolences to you!
In my opinion, the most important thing is that you actually understand all the code as it is today. Minds better than mine may be able to simply read the code and understand it. However, I can't.
After reading the code for a general overview, I usually repeatedly single step through it in the debugger until I begin to see some patterns of operation and recognize code that I've read before. Maybe this is obvious, but thought I'd mention it.
You might also think about creating a good test suite that runs on the current code.
Does the interface section contain a bunch of class definitions? If so, create a new unit for every class and move each class to it's own unit.If you use Delphi 2007 or better, you can use the "refactor/Move" option to move those classes to the new (namespace) units.The next step is splitting the large classes into smaller classes. That's just a lot of manual work.Once your code is divided over multiple units, you can examine each unit, detect identical code and generate base classes that would be used as parent for the two classes that share similar functionality.
In addition of understanding the code etc, these tools may help refactoring and reorganizing the project:
Model Maker is powerful design, reverse-engineer and refactoring tool: http://www.modelmakertools.com/modelmaker/index.html
Model Maker Code Explorer is powerful plugin for Delphi IDE to help with refactoring, code navigation etc: http://www.modelmakertools.com/code-explorer/index.html
I would use some sort of UML tool to generate som class diagrams and other diagrams to get an overview of the system, and start splitting up and commenting like #Workshop Alex said.
Use a tool like Doxygen to help you map the code.
Help on that is here
Start out small and eventually do a partial or full rewrite. Start creating base classes to accomplish pieces of the puzzle without changing the output. Rinse-repeat until you have a new, supportable codebase.
Once you hit those copy-n-paste routines, you'll have base classes to do the work and it'll really help accelerate the task.
Which one of these would fit a top down shooter better?
I've heard that Box2D performs faster, but I've also noticed that it lacks wider community support for XNA (it rather seems to be used for flash - for a reason unknown to me).
Farseer is however built for XNA, and seems to fit it and perform pretty fine. Farseer's advantage in my opinion is also it's clean, easy to use API (also it'd fit my game-engine's structure perfectly). However I'm affraid I'll have some drawbacks if I use it (bullets and high speed bodies? strange not a number crashes?)
Overall I'd appreciate if you'd point out which one fits better XNA/PC development.
Reasons why I need this:
It is not going to be used only in one top-down shooter, it's meant for integration with game framework.
Even a top-down shooter would be more appealing in an environment with better collisions, realistic physics - for example you could move a box to get into cover?
Manual control of collisions in an pixel perfect manner would be too expensive (I don't have time to optimize it - nor I need it if high-performance physics engines with advanced collision detection algorithms exist out there), whilst bounding box collision is way to unrealistic.
Do I deserve an answer with your opinion now? Please keep it straight and tell me did I make a wrong step by using Farseer instead of Box2D? (I had to start working while waiting for an answer.)
Thanks in advance
Why use a physics-library in a top-down shooter ?
I think all you need is some basic collision-detection / handling.
Running a complete physics simulation seems a bit over the top.
Edit:
Personally I think I'd go for Farseer, I've heard good things about it and it seems to be well supported. The point is that for a decision based on arguments, one would first need to know exactly what it will and won't be used for, what you expect of it in terms of functionality, speed and supported platforms, what you expect in terms of support, etcetera. Just asking "What physics-lib should I use for a topdown shooter" is not enough information. Especially if you edit it later on to say it's actually not for a topdown-shooter but for general use in a game-engine :-)
I'd go with Farseer for sure (although I've used it previously so I am biased). It has a lot of examples and even has some specific optimisations for the .Net compact FX. Internally it is based on Box2D (yes it is a slightly old build) but it is being actively developed all the newer features of Box2D are pulled across. The API is mature, clean and easier to use than Box2D. If all that doesn't sway you, then this should: http://ianqvist.blogspot.com/2010/12/benchmarking-box2d-based-physics.html
I definitely suggest using Farseer, it has been in development for long (>3 years) and I think its major flaws have been corrected.
Let's say that you have to implement some functionality that is not trivial (it will take at least 1 work week). You have a SDK/API/library that contains (numerous) code samples demonstrating the usage of the part of the SDK for implementing that functionality.
How do you approach learning all the samples, extract the necessary information, techniques, etc. in order to use them to implement the 'real thing'. The key questions are:
Do you use some tool for diagramming of the control flow, the interactions between the functions from the SDK, and the sample itself? Which kind of diagrams do you find useful? (I was thinking that the UML sequence diagram can be quite useful together with the debugger in this case).
How do you keep the relevant and often interrelated information about SDK/API function calls, the general structure and calls order in the sample programs that have to be used as a reference - mind maps, some plain text notes, added comments in the samples code, some refactoring of the sample code to suit your personal coding style in order to make the learning easier?
Personally I use the prototyping approach. Keep development to manageable iterations. In the beginning, those iterations are really small. As part of this, don't be afraid to throw code away and start again (everytime I say that somewhere a project manager has a heart attack).
If your particular task can't easily or reasonably be divided into really small starting tasks then start with some substitute until you get going.
You want to keep it as simple as you can (the proverbial "Hello world") just to familiarize yourself with building, deploying, debugging, what error messages look like, the simple things that can and do go wrong in the beginning, etc.
I don't go as far as using a diagramming tool sorry (I barely see the point in that for my job).
As soon as you start trying things you'll get the hang of it, even if in the beginning you have no idea of what's going on and why what you're doing works (or doesn't).
I usually compile and modify the examples, making them fit something that I need to do myself. I tend to do this while using and annotating the corresponding documents. Being a bit old school, the tool I usually use for diagramming is a pencil, or for the really complex stuff two or more colored pens.
I am by no means a seasoned programmer. In fact, I am learning C++ and I've been studying the language primarily from books. When I try to stray from the books (which happens a lot because I want to start contributing to programs like LibreOffice), for example, I find myself being lost. Furthermore, when I'm using functionality of the library, my implementations are wrong because I don't really understand how the library was created and/or why things need to be done that way. When I look at sample source code, I see how something is done, but I don't understand why it's done that way which leads to poor design of my programs. And as a result, I'm constantly guessing at how to do something and dealing with errors as I encounter them. Very unproductive and frustrating.
Going back to my book comment, two books which I have ready from cover to cover more than once are Ivor Horton's Beginning Visual C++ 2010 and Starting Out with C++: Early Objects (7th Edition). What I really loved about Ivor Horton's book is that it contained thorough explanation of why something needs to be done a certain way. For example, before any Windows programming began, lots of explanation about how Windows works was given first. Understanding how and why things work a certain way really helps in how I develop software.
So to contribute my two pennies towards answering your question. I think the best approach is to pick up well written books and sit down and begin learning about that library, API, SDK, whatever in a structured approach that offers real-world examples along with explanations as to how and why things are implemented as they are.
I don't know if I totally missed your question, but I don't think I did.
Cheers!
This was my first post on this site. Don't rip me too hard. (: