Jump to content

JeZuS

Members
  • Posts

    34
  • Joined

  • Last visited

Everything posted by JeZuS

  1. I actually realy like reading it. I just wish I had the time to attemt something like it myself. Mind you, I SUCK with vectors and 3d graphics. Not helped by the fact that I installed VS2005 C# express along with XNA in a VMWare virtual machine, which I then found out won't work as it requires hardware excelleration. #sigh#. I'll take a look though.
  2. Hey NordWindRanger, I noticed on your blog that you were having trouble with firing code. Do you have the trouble even if the ships are not moving?
  3. Actually, that is not right. The .NET JITer caches compiled code, so it would only be run through the translater once, and possibly ahead of time. From MSDN: "Since the MSIL is being compiled just-in-time (JIT), this component of the runtime is frequently referred to as a JIT compiler or JITter. Once the JIT compiler has compiled the MSIL, the method's stub is replaced with the address of the compiled code. Whenever this method is called in the future, the native code will just execute and the JIT compiler will not have to be involved in the process. As you can imagine, this boosts performance considerably." Well, sort of. Except the only real inplimentation of .NET is really the MS Windows one Mono is getting there. I admit I have not looked that direction if a while. Spot on about DirectX though, so as you say it may be a moot point. On a side note, MS actually have released a free game programming C# version of the VS IDE, complete with more examples then you could ever use. http://msdn2.microsoft.com/en-us/xna/default.aspx But hell, when it comes down to it, use what you feel comfortable with.
  4. Just to folow up on this; I would say the performance hit would be pretty minimal, if any, as they would be looked after by the jitter. However yes, they would still need to be compiled into packages/dlls.
  5. Hhhmmm looks interesting. I like the idea! I will be sure to keep an eye on it. Good luck!
  6. Ah, so you are actually in the process of making a Rebellion2? What language and graphics engine are you using? (just in case ther is any way I can help)
  7. What would you change? (pie in the sky ideas) If Rebellion2 was being made by a team of developers with lots of experience, unlimited resources and too much spare time ontheir hands under my control, what would I have them do differently? There have always been things I wanted to be different in Rebellion, but never really thought to much about them as there was a snowballs chance in hell of anything being done. But the thoughts of Rebellion2 sparked off that particular part of my brain. My main problem was/is the space battles. On a couple of fronts. Firstly, until the advent of Interdictors, it was impossible to trap you opponants fleet. They can just jump away as you start from miles away. Your fighters will get a few shots off at best. I normally end up splitting my fleets up to lure the AI in. What I want is a way to to trap fleet and force them to fight. How this would be done is something I have not previously figured out. What I am currently mulling over is this: Possibly have 3 levels (pick a number) of levels of orbit in a system? That way you could dictate where in a system you orbit, but you can only jump if you are the outermost fleet (efectively a fleet at a higher level could block you in). This way you could effectively trap fleets (or be trapped). To escape, a trapped fleet would need to fight its way out, running the gauntlet in the 3d battlefield of the outer fleet. Additionally if you happen to jump to the same level as a fleet already in orbit, then the battle would start with fleets practically on top of each other. Instant brawl! Further to this, there needs to be anadvantage to being in a low orbit, or else you would never go there. What I think would work is this: Only at a low level orbit can you launch a ground assult. But if an enemy fleet attacks your system and jumps inside your defending fleet, then it can assult without nocking your fleet out. This makes the orbit system a two edged sword. A bit mor realistic IMHO. But wait you say, you can'thave two fleets in the same system.... Can you? Why not? there could be a stand off perhaps? Allowing both fleets to remain at different orbits? (this would llow either fleet to bring in reinforcements before attacking, or simply use a fleet to cover a ground assault. Or... Perhaps, don't allow two opposing fleets in orbit, but DO allow similtanious ground and space battles? An attacking fleet could then try to escort its assult/transport vessles to the planets surface. The make up of the assult success would depend on how many vessles you could safely get to the planets surface. Other then the systems stuff above, the other thing I would like is more control over fighter squadrons. Just yesterday I wanted my x and a wings to defend my b and y wings going for a capitol ship. Instead they fly across the map to some other squadron of TIEs and leave the bombers to get slaughtered. There are two ideas of mine, your thoughts? Jez.
  8. Lol, FWIW neither was C++ But he/she is right, for sheer gut wrenching speed at high end, professional grade graphics, there is no competitor to C++. Delphi is not far behind (Due a lot to the fact it uses a C++ compiler and has full, direct access to the WinAPI). VB6 will cost you a fair performance hit, plus it is now practically abandonware. the .NET languages are going to be slower then C++, but have IMHO performed quite well in what I have seen. However, I have to contend that the speed difference is not going to be your major concern. What you need is developers. Anything you can do to make it easier for people to contribute to your project is going to be worth its weight in gold. If you have a solid stockpile of C++ devs, go for it. But if you don't, then C++ is going to be significantly harder to get started in then C#VB.net/Delphi or even Java (which I think is fairly unsuited, by the way. It would however open up a large pool of potential developers). Harder = people less likely to commit and help. a 5-10% speed increase isn't any good to anyone if the game never gets made. Besides, as far as gut wrenching speed goes, the original Rebellion ran on my Pentium 75 no worries. If what you make doesn't run decently in any modern language/framework on even a now antiquated PC, then there is a significantly greater problem in the code... +$0.02c
  9. I think .NET might be the way to go as you can get a series of different language developers together. As I use Delphi, it doesn't matter much as I can make DLL's for VB or C++, or use .NET or C#. However you will have much to gain by using something as generic as .NET which will allow almost all to participate. Plus, as nordwindranger mentioned, .net languages are freely available. Either in the Microsoft Express editions (http://msdn.microsoft.com/vstudio/express/), the Delphi and C#Builder Turbo edditions (http://www.codegear.com/Downloads/TrialandFreeVersions/Turbo/tabid/144/Default.aspx) and possibly some others.

Copyright (c) 1999-2025 by SWRebellion Community - All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Star Wars(TM) is a registered trademark of LucasFilm, Ltd. We are not affiliated with LucasFilm or Walt Disney. This is a fan site and online gaming community (non-profit). Powered by Invision Community

×
×
  • Create New...