Author
|
Topic: A star control 1 remake that may actually get finished (Read 38531 times)
|
Mormont
*Smell* controller
 Offline
Posts: 253
I love YaBB 1G - SP1!
|
Giving ships more firing angles sounds good in theory, but it might really mess with game balance. Though there's no Druuge in SC1 (the ship that would probably benefit from it the most). But the dreadnought hardly needs any more help against the SC1 ships.
One thing I would love to see one day is a SC1 strategic mode with all the SC2 ships added in, with the ability to create both story scenarios like SC1 and custom teams like SuperMelee...I actually tried to start writing one a few years ago, before I realized I was in way over my head.
|
|
|
|
« Last Edit: May 22, 2009, 05:42:21 pm by Mormont »
|
Logged
|
|
|
|
UAF
*Many bubbles*
Offline
Gender: 
Posts: 134
Robot in Disguise
|
More angles change game balance. I wouldn't say that it ruins it though.
TW had it, and I never felt that it's unfair when I was playing a small ship against a big one (and big ships get the most from that change).
It might make the skill required to beat a big ship with a small one higher, but I don't think it's that bad.
(Arilou vs Kzer-za, Umgah vs Chenjesu, etc).
|
|
|
|
|
Logged
|
|
|
|
|
|
Bigryan
Frungy champion
Offline
Posts: 56
|
wow. some more fabulous art.
Using smalltalk may make things simpler. I'm using strictly c++. Kindof crazy, as I'm running into some memory issues.
Are you using smalltalk just to do some scripting? or is smalltalk going to be where the bulk of the the work is done?
|
|
|
|
|
Logged
|
|
|
|
Dragon
Frungy champion
Offline
Posts: 86
|
Oops, I forgot to mention that I made an unbelievably stupid and costly coding mistake in my Smalltalk interface implementation. I know how to solve it but I'm still having a bit of a sulk about it so there's been a small change in plans.
In an effort to actually get something out *ever* I'm shelving Smalltalk until after I'm done with SC Redux which means all the gameplay will be written in C++. This gives me time to work out a number kinks in my engine which is why I'm posting strange and broken dev shots again (the Ur Quan is not supposed to have glowing pink legs).
And as for C++ and memory issues, that's pretty much par for the course. I've just (this evening) dug up a new and bizarre leak. As I don't like fighting memory issues I sort of wrote my own reference counting memory manager (also Smalltalk needed it) but... if that memory manager leaks it doesn't help. Fixing that brought my number of memory related test cases to slightly over 1800 (actually 1808) which probably shows that C++ and memory is generally an unhappy place to be.
ps: Make sure you've turned on memory leak detection in DEBUG in whatever environment you code in. It's invaluable.
[EDIT for scripting clarity]
The design so far has been that a scripting language (I finally chose a Smalltalk) must run all the gameplay. The backing engine must be totally disconnected from the style of game I'm writing which would make it reusable for - say; off the top of my head - a Space Crusadish remake. I'm trying to avoid the pitfalls of variously: The Unreal 3 engine where the (retarded) scripting language is tied to closely to FPS gameplay; Torque Game Engine where too much of the engine functionality was moved to the scripting language making it slow (although there are work arounds); and RenderWare which is so damn general that one needs to basically write an engine on top if it anyway.
This whole engine writing lark is hard 
|
|
|
|
« Last Edit: May 27, 2009, 10:20:43 pm by Dragon »
|
Logged
|
|
|
|
UAF
*Many bubbles*
Offline
Gender:
Posts: 134
Robot in Disguise
|
Why C++ and not C# or Java if you want to avoid memory leaks?
Garbage collectors are just for that, aren't they?
|
|
|
|
|
Logged
|
|
|
|
|
|
Bigryan
Frungy champion
Offline
Posts: 56
|
I thought of using java at one point too, with jogl, it's actually quite nice.
You also get multiplatform almost for free.
In the end i also settled on c++ just because it was more stable and seemed to be quicker. Java was eating my processor.
There was also a lot more 3rd libs in c++.
I would love the garbage collection of java, but with jni native code you do still have worry about memory. No getting around it.
|
|
|
|
|
Logged
|
|
|
|
Dragon
Frungy champion
Offline
Posts: 86
|
I thought of using java at one point too, with jogl, it's actually quite nice.
I would love the garbage collection of java, but with jni native code you do still have worry about memory. No getting around it.
The big problem with going a Java only route is that JNI calls are expensive. Very, expensive. Using java to call, say, draw vertex for every single vertex alone would kill your app stone dead. Being a bit more intelligent and drawing, say, 10000 verticies with a single JNI call is much better but any state change calls are still going to hurt. Alot.
I really wish there was someway of telling Java (and as far as I know this is a Java issue not a JVM issue) that I'd like to do fast unsafe JNI calls because I'm willng accept the consequences of getting it wrong. Alas this isn't possible. However the GNU guys with GCJ using GNU's common whatever calling convention managed managed to do JNI calls almost as fast as doing a straight c++ call. Unfortunately GCJ hasn't moved in years and seems to have died a quiet and unremarked death. A pity because I liked it.
None of this gets around the fact that, yeah, one still has to manage one's own resources. The garbage collector can't do that for one.
C++ FTW.
|
|
|
|
|
Logged
|
|
|
|
UAF
*Many bubbles*
Offline
Gender:
Posts: 134
Robot in Disguise
|
I know I'm only a very new programmer (fresh out of a C# and JAVA course) but it is a bit discouraging that I have NO idea what you are talking about most of the time.
What's a vertex? what's a vertices?
What's JNI? GNU? GCJ?
Should I be bothered that I don't know what all those things mean?
And most of your previous posts?
|
|
|
|
|
Logged
|
|
|
|
Spurk
*Many bubbles*
Offline
Posts: 115
|
Not much of a graphics person myself, but I do know Java, so I'll give quick answers.
Vertex, as you may remember from geometry, is a corner. In a cone, the vertex is the point that everything converges to. In a square, it's one of the four corners. Vertices is the plural of vertex.
JNI stands for Java Native Interface. Java is designed to be run against its own virtual machine, so that it can achieve that write-once-run-anywhere ability that lets you write a Java program on Windows and run it on Linux. Unfortunately that means you can't use any non-Java libraries in your program and you can't get access to the real machine that's running the virtual machine. So JNI is a way for you to be able to do that. It lets Java talk outside of its little box to the actual computer. JNI is not normally a preferred solution for a lot of things (because it is expensive and breaks the run-anywhere part).
GNU stands for GNU's Not Unix, which will make your head hurt if you think about it too long. It's a project to rewrite all of Unix into a free version. If this sounds like Linux, you're not wrong (Linux is sometimes called GNU/Linux), but the actual history is more complex and confusing. As much as Java is free to download and use, the GNU project decided to write their own version, calling it GCJ, the GNU Compiler for Java. I don't know too much about GCJ as Sun's Java Development Kit (JDK) is the de facto standard, and what I use for all my work.
To rephrase Dragon's last post, since Java3D is crap, he'd have to go outside Java's virtual machine for graphics, which would really slow things down because Java forces checks to make sure you're passing in and getting back what you think you're passing in/getting back. However (and I find this interesting), Dragon believes the overhead on making JNI calls is at the language level, not the virtual machine level, so it should theoretically be possible to make JNI calls that are much less onerous. Apparently GCJ had a good take on this problem as well, but the GCJ project seems to have not had much activity recently, so that's not a good sign. But even if JNI did work like he wanted, all his JNI stuff would still have to manage its own memory/resources. Java's garbage collector can't handle memory/resources allocated through JNI.
|
|
|
|
|
Logged
|
|
|
|
Dragon
Frungy champion
Offline
Posts: 86
|
Ta Spurk, that's it exactly (saved me from another long winded reply).
A bit more detail on the verticies thing. In most 3D scenes everything is made out of triangles. To draw a triangle one needs to 'draw' the 3 corners (vertices). In OpenGL there is a method which 'draws' a vertex. Once it's been called three times a triangle is actually drawn.
Aside: Even without involving JNI drawing each vertex individually is slow. It's better to call a method (say drawTriangle) which takes three verticies at once. However it's best to call a method which takes a lot of vertices (thousands) and draws all the associated triangles in one shot.
|
|
|
|
« Last Edit: June 09, 2009, 08:14:17 pm by Dragon »
|
Logged
|
|
|
|
|
|
UAF
*Many bubbles*
Offline
Gender:
Posts: 134
Robot in Disguise
|
I'm really glad the project doesn't use UQM's code and graphics.
Better graphics and more angles for ships rocks.
But that's just me 
|
|
|
|
|
Logged
|
|
|
|
CelticMinstrel
Enlightened
Offline
Posts: 522
|
Yet, that means it's a different game, though the premise at least is the same.
|
|
|
|
|
Logged
|
|
|
|
|
. Smalltalk is, just for interest, still about a decade older than C++.