Ciao!

I am generally bored having finished or cancelled many of my outstanding projects. I decided to make a Java clone of Uplink (perhaps not an exact clone, as there are things in Uplink I don't overly like and so on). I have a display for one working with hand coded garbage management and a restructured rendering pipeline for awt/swing. So far all the graphics are vector and made on the fly, which negatively effects its preformance currently, but I will replace it soon with overlay and on the fly image cacheing (so it will stand up to the opengl rendering in the c version of uplink).

I am only working on this in my free time so don't expect much very quickly.

Since uplink doesn't require much heavy processing aside from the display in some places, such as the moving dotted paths, preformance in java will not be a problem. Truely the greatest challenge will be sure to avoid the memory bloat, so far its running in about 30mb including the java runtime environment. While this is pretty good for a java app I hope to be able to reduce this some or atleast keep it around this level.

EDIT:
Here is a screenshot of the basic graphical elements layed out. Nothing very impressive, but just to show you that it does actually exist and I am not just talking out my bum.

Screenshot: http://www.csdgn.org/img2/screen.png

I had the forethought to run the display in a seperate thread to avoid slowdown in the game due to the graphics. This by itself sets itself up as a basic frame skipping routine. Now I am sure most people don't care, one way or another. But this is me when i'm bored.

Allow me to direct you to one of my previous topics:

viewtopic.php?f=52&t=741

I see alot of 'wondering why' someone would do this. My reason is explained in the post title. I may not finish, finishing is not a goal. My goal is to make it fast and generally memory efficient for Java (which is hard and thus a challenge). I also am forgoing using openGL (which uplink uses) and isntead using the built in graphics (awt/swing) just to make things a bit tougher (I have gotten a program with over 100k different moving objects to render at a little over 100fps with some optimizations and work arounds, and yes I did correctly calculate the fps, I checked.).

Going for gold I am also breaking the program into two threads, one for the display and the other for the 'game' part. Therefor the game will not be slowed down by the display, which may in turn run as fast or as slow as it pleases.

In any case, here is something to tide anyone actually interested over.

A exe wrapped version of the Jar: Get it here

For those who don't want to bother with the whole bat/jar thing. This is just a display build, meaning no game mechanics are in place yet.

I am aware that all buttons move thier containers around, this was intentional, I was testing the textbox movement.

Some things still render without my permission meaning there is flicker, I will try to get that nailed down by the next alpha display release (mostly because it bugs me).

Not to entice you, but we have a shortage of people in the know with OpenGL... though I'm not exactly certain what Java has in way of it.

(Also, not to nitpick, but "alot" isn't a word. It's either "a lot" or "allot" [think: allocate]. It's just one of those typos that drives me nuts, not trying to call you out or anything)

There are a few opengl wrappers for java, some direct (LWJGL) some more abstracted (JOGL). I have a huge headache so I might of gotten those two mixed up.

I have done some work in GL but i'm not an expert, and I find it very tedious. Also since java uses wrappers with it, it was not an ideal choice. I have not done it extensively since my days working with C++ (Which we're brief). (So i'm not the person to ask, I 'know' you know more then me by this point)

Also packing it and its dll's and libraries into a jar is not the simplest of tasks (well atleast so they load automatically).
Sorry for that, I know that, but my fingers are programmed from years of typing it wrong (I am sure you know what I mean.). So changing it is hard and I don't tend to proofread my forum posts (I know I should).

I guess I will give writing an openGL version of the display a shot.

Actually, my 8th grade English teacher told us that it is used so much, "they" (the people who decide what's in the English language I guess) are considering making it proper English. However, obviously this change has not occured, so "alot" is still incorrect.

As far as OpenGL in Java, I'm pretty sure JOGL is the official implementation of it, but I'm not sure.

Actually it turns out that the Java2D is so anal on its painting, that I can't stop it without also destroying my pipeline in the process (as it relies on a number of the calls that I would have to nullify/override). While i'm sure this makes it great for most programs, its just a pain for mine.

My only other option I would have is to build and track everything on my own, meaning all I tell it is to give me a blank screen, and I do the rest with non-awt/swing stuff. While I have done this on small scale I am not sure if I want to attempt it in something of this size. But for the heck of it i'll make a prototype of such a system. But tomarrow, as I am wiped.

Also I ran some OpenGL through and it doesn't look to bad, but unless I setup the rendering just right the preformance crashes, ending up lower then what I can achieve with J2D, so I am not going to bother using JOGL. Its harder to code in and harder to keep it rendering quickly. (While normally I would rise to such a challenge, its not really hard so much as it is tedious, and I hate tedious)

Once I make a build of Oasis, the handbuild graphics system I mentioned above. I will dump another wrapped alpha.

Might "Oasis" become open-source?

Hrm, no, for a very simple reason, I decided to dump it for 'Quantum', one that should play nicely with awt/swing instead of abusing or replacing it.

In other news, Miah asked me to make a Gateway Modification program, i'm not done, but here is what I do have.

Note: It doesn't save yet and only cpu, security and memory can be created.

The left hand bar will have some generic options like, snap distance, snap same kind only, ruler, grid, show snap, and some basic painting tools. I hope to add a better design area where you can define the actual size of the output gateway (perhaps resizing of the borders there, that might work).

Forgive me, as I have only worked on this app for a few hours, as I have a date to go on (Surprised I have a social life? o.O).

You can grab the early pre-alpha here: Get it here

Okay, here is another one, you can actually 'save' with this one, it has everything but the Ram and SataII parts, the grid snap, and those misc painting tools I was promising (all those are in the works). I am working on getting the smaller thumbnail image to autogenerate aswell (means I have to scale the image, not hard to do, but I also need to make it a specific size, which is a bit harder). I plan to make the image width and height a multiple of 50 in r3 (on par with the original uplink gateways).

It writes currently in png format, java doesn't come with something to write tif images, and while I could create my own tif image writer, I was more concerned with getting it working first.

OH, also most the parts will not align right, in fact I am fairly sure they all will not be aligned correctly, but I will fix that for the 3rd release.

You can grab the beta here: Get it here

I got out of the vapourware business awhile ago. Also unlike my uplink clone, this one is I haven't spent any time working on the speed or memory usage, so it is probably pretty horrible. (I'll look into that for r4).

Very nice work.

Wait till I actually get it fixed and working, but I have work to do so, maybe wednesday I can work on it some more, or ealier if I find some free time.

Okay here it is, release 3. The available parts align correctly, its only missing sata2 at this point (i'm lazy lazy). IT encodes into tiff format using LZW compression, if this turns out to be incompatible with onlink (shouldn't, it works here). I can set it to write uncompressed tiffs instead.

It also writes the thumbnail, which after 3 rounds vs the java virtual machine I came out victorious with a KO, it now cooperates without any problems (and has correct scaling). (though in the last round I cheated by using a big wooden bat instead of boxing gloves)

I still haven't gotten on those drawing tools, but the first of those are slated for the next release, r4.

I also tackled a few of the more grevious memory problems. It shouldn't use more then 64mb where as before it capped over 120 on mine. Next i'll work on forcing that CPU time down, (like when its out of focus etc)

You can grab the second beta here: Get it here

Also, never code while wide awake, you produce worse code then when severly sleep deprived and on your 3rd caffeine fueled day.

EDIT: Arrg! Fix your code in onlink, positions parts via the order in the text file, not what the first part of the line says. (I'll fix this for my r4 so things come in the correct order!) For now just move sec section to before modem of the text entry to get it to work right.

It should be fine. In fact, Onlink should accept all forms of TIFF compression, including JPEG compression. The TIFF files in data.dat are packed with LZW (at least the new news as of 0.1.2. In 0.2.0, they are all repacked).
I find it funny howyou think of your code. For me, I think of it like a totalitarian state. I beat it into submission during the testing phase, and during the QA phases, I commit genocide.

My last commit was a net removal of over 2000 lines of code. This was due to my unification of tasks, each Uplink task (File_Copier, Log_Deleter, etc) has a lot in common with the others. Certain rendering code, actions like the close button etc. These were originally called in each task. Now they are only called in the task superclass. Should cut the code size down a bit. I would like to think so, anyway.
I frankly didn't expect you to go this far. I was thinking that having it load a tiff so that people could generate just a text data file would be nice, but this works even better. Would you at least add the option of loading a previously generated TIFF?

Oh, and do you know the limitations on sizes for Onlink's gateway TIFFs? I don't have them to the pixel, but if you don't know them, I can find out.
Huh?

EDIT: I should note that Onlink accepts all forms of TIFF compression, but Uplink (the last time I checked it, and except for Mac builds) does NOT. Please remember this if you're shooting for backwards compatibility.