Author Topic: Moving Pictures  (Read 16771 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4952
Moving Pictures
« Reply #50 on: January 05, 2012, 04:51:03 AM »
Lol. Things sound pretty sweet over there in performance land.

I was half wondering if some of those tasks were completed in the background, given the small times for the large amount of data, but I'm doing a few mental calculations, and both examples do work out to about double the typical speed of a fast SSD. Right about what you'd expect for RAID striping. Very nice.



Hmm, how would the client know to send a team colored rectangle? I would assume the graphics themselves would be on each client, so only simple things like the coordinates and team color would need to be sent. If you knew enough to draw a box, wouldn't you know enough to draw the full image? Or are you sending the actual image itself over the network?
 

Offline WooJoo

  • Jr. Member
  • **
  • Posts: 90
Moving Pictures
« Reply #51 on: January 05, 2012, 04:58:15 PM »
that sounds like quite the overhead your creating which is not needed. I would be simpler to set the area coordinates to each host and let them do the render work instead of sending image files all over the intertubes. or do i missinterpret this whole story?

Offline RobbixTheBobbix

  • Newbie
  • *
  • Posts: 21
Moving Pictures
« Reply #52 on: January 05, 2012, 07:21:20 PM »
WooJoo, I think you did. The server provides the clients with any sprites/tilesets it does not already have as my version of this game is intended to be more flexible, dynamic, whathaveyou. It's not going to send every image over every frame.

Hooman - the client would draw the colored box if it had not yet dynamically loaded the sprites; sprites can be pre-installed by the player before starting the game, installed automatically server->client before game starts, or even loaded on the fly after the game has already started, as necessary.

I'm thinking the clients will have LocalGameMaps which are updated by the client as it receives visible events from the server. There will be no LocalEngine that executes unit behaviors or environmental events.

I know this is confusing as this all seems unnecessary, but as this project is more an exercise for me in software design than an attempt to make a perfect replica, it sounded cool so I started adding it.
 

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
Moving Pictures
« Reply #53 on: January 07, 2012, 08:25:35 AM »
An idea that I once had for another similar project was to have each player's machine do the logic for that player's units (i.e. path finding etc.), but only send the events for the next few milliseconds over the network. For example, a complete path would be calculated on a players machine for a unit controlled by that player, but instead of sending the whole path at once, only the part that is needed immediately is sent and other parts are sent when needed. The advantage would be, that time intensive calculations would not be done all on one machine. It would also take away some of the network lag that would be there if every command had to go through the host.

I'm not sure how this could address the fog of war concern. Not sure if we'd even want fog of war. Apparently you want each player's machine to only receive what that player can really see on his/her personal map. For that, the sender may only send what that player can see and for that the sender must know what that player can see. If that is the case the sender knows already more about that player than is desired.

There are also things like research which you'd want to have monitored by a trusted machine, since otherwise it would be possible to claim that a research is completed when no scientist had been assigned to it.

So, the question is whether to have all machines know almost everything or have only one machine know almost everything.

Offline jcj94

  • Sr. Member
  • ****
  • Posts: 407
    • http://techfusion-279.com
Moving Pictures
« Reply #54 on: January 09, 2012, 08:16:52 AM »
I'm back for a few, and figured I'd check up on this.

FOW seems like a good idea at times, but I've noticed that in a few RTS's, the AI doesn't like to follow the rulings on that.

I prefer OP2 -without- Fog of War, but still having units be invisible on a minimap when they have thier lights out.  Thats a stratagy I've grown used to as of late.

The AI should be done on the server machine, be that a players machine or on a 3rd party system.  

Player pathfinding should, as TH300 said, be done by the players machine.  It would also allow quicker changes to a swapping of pathfinding.  If a player needs to rapidly swap out a path and the server has already loaded a path, there might be increased lag.  Not a lot, but most definately some.

And what is the intended final max player size?  Personally I'd love an FFA with 8-10 people in it, even if 6 of them are AIs.

*waddles back off into the corner while school consumes my life*

Offline RobbixTheBobbix

  • Newbie
  • *
  • Posts: 21
Moving Pictures
« Reply #55 on: January 15, 2012, 08:45:21 PM »
I;m starting to consider re-making this as a C#/.Net app from Java. Using .Net at work as turned me, it seems. The current Java version is still pretty slow and uses incredible amounts of memory.

Of course, this would kill the cross-platform compatibility aspect of it. The current version runs fine under linux.

Is this a real problem for anyone? Who out there runs linux or osx? Is it that big of a deal if I can get to run perform much better?

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4952
Moving Pictures
« Reply #56 on: January 16, 2012, 09:40:03 PM »
Now to say something subversive, like...
Hey, why don't you code it in assembly? That could certainly help performance. Plus, since Windows/Linux/Mac computers all run on x86, the only non-cross-platform code will be calls to the OS API. ;)


Also, check into Mono. Apparently you can run some .Net stuff on Linux. Although, I hear the features are generally lagging a bit behind. I don't know any specifics though as I've never much looked into any .Net stuff. (Yeah, I'm a bit of a dinosaur now).
 

Offline jcj94

  • Sr. Member
  • ****
  • Posts: 407
    • http://techfusion-279.com
Moving Pictures
« Reply #57 on: January 17, 2012, 09:01:17 AM »
Well I can play games, Amnesia and the like, on Linux no problem.  I haven't tried Terraria (which needs the .net and .xna frameworks) yet however, and will probably try sometime in the near future.  Wine is -so- useful for that.

As far as OS compatability.. I think everyone probably has a spare computer lying about with Windows XP on it.. or could easily get one.  I mean, its not like this lags to death on an older machine (4 copies of Op2 on my 512mH processor with 512mB of RAM, no lag whatsoever), assuming you keep true to the OP2 stats on performance.

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
Moving Pictures
« Reply #58 on: January 17, 2012, 04:48:47 PM »
I only have Linux.

Before you're considering different languages/frameworks, you should consider different Java libraries. I mentioned that in an older post. You could use SDLJava and/or JOAL or possibly LWJGL and the nio classes. All of those are not too much platform dependent.

And don't forget that speed and memory usage are also influenced by how your code works.

Last time I tried Mono it wasn't at all able to run the .Net program that I wanted to use. That was long ago, though. Btw. Mono and Wine are entirely different things. Wine works quite well as of today, but that tells us nothing about Mono.
« Last Edit: January 17, 2012, 05:11:20 PM by TH300 »

Offline Fenrisul

  • Full Member
  • ***
  • Posts: 153
Moving Pictures
« Reply #59 on: January 20, 2012, 01:58:03 AM »
Mono works just fine on Linux - its good enough for Android/iOS too.  It doesn't have piss all for graphics libraries that run well on Linux though :(

Offline RobbixTheBobbix

  • Newbie
  • *
  • Posts: 21
Moving Pictures
« Reply #60 on: January 21, 2012, 11:32:46 AM »
OK, don't worry too much about moving to .Net. C# has some neat-o features, but making this into a WinForms app didn't help at all. WinForms seems to have worse performance than Java2D. Just drawing a 16x16 terrain was sketchy.

Though it did seem to use less memory. I didn't get very far with a WinForms version, but the current Java version uses ~200MB of memory just for an empty 256x128 map. Seems like alot. The original OP2 used 14M for a map twice that big.

And if you add a bunch of units to one corner of the map and select them all and tell them to move to the other side, there's a several second delay.

Hmmm... Java7 has support for running multi-core tasks. I know my pathfinding is simple and inefficient, but I'll probably try to take advantage of that in any event.

Anyways, about OpenGL: I'm trying out OGL for java right now, so far, all I have is a spinning box and a single Scout sprite. Seems like it would take a long time to rework what I have for JOGL. I wonder what kind of performance impact there would be in switching, though?

----------------------------------------------------------------

Quote
"Now to say something subversive, like...
Hey, why don't you code it in assembly?"
No. Just No. Get out.
...of your own forum.

This project is intended to be something that is easily modifiable, even for novice programmers. Assembly code would make that difficult. We wouldn't be any closer to having OP2 source code than we are now. Would a version written in ASM be any more readable than a dis-assembly of the retail exe?


-------------------------------------------------------------------

Thanks for everyone's continued interest, btw. I appreciate input, even if it chills me to the bone (i.e. Assembler).
« Last Edit: January 21, 2012, 11:34:31 AM by RobbixTheBobbix »

Offline Fenrisul

  • Full Member
  • ***
  • Posts: 153
Moving Pictures
« Reply #61 on: January 22, 2012, 11:05:10 PM »
Theres always SDL for java

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4952
Moving Pictures
« Reply #62 on: January 25, 2012, 02:12:42 AM »
Ok, how about JavaScript then? ;)


Also, I would expect code changes to the Java code could drastically reduce memory size. I know Java is kind of known for being a memory hog, and some of that is just the runtime before your code even gets a chance to start, but mostly, I think the language design encourages certain coding patterns that create a lot of temporary objects. If you learn how to avoid creating excessive temporary objects, you can probably decrease the memory usage substantially, while also likely improving performance.
 

Offline RobbixTheBobbix

  • Newbie
  • *
  • Posts: 21
Moving Pictures
« Reply #63 on: January 25, 2012, 06:35:11 PM »
Quote
Ok, how about JavaScript then? ;)
You...
You...

-----------------------------------------------------------

Hmmm... I found a very wasteful part of the DisplayPanel where it's generating a whole ton of Position* objects, and factored it out. Still doesn't explain the 200MB. From what people are saying about Java games, this is to be expected. And when it loads all the sprites, memory grows even more, as the sprites are stored as individual composited frames instead of tiny parts of an image with metadata, like original OP2.

Position is a simple but very helpful class that basically consists of:

class Position{
final int x, y;
}

with lots of helper methods and uses elsewhere. Makes for cleaner code, but creating and passing all these around is quite a load. I was profiling a run of the game once and the profiler said there were 100's of thousands of Position objects floating around. Those, and int[]'s The int[]'s are probably existing as members of BufferedImage's though. Hm....

If only I could have value types in JVM. You know, I actually considered starting to pass around simple objects like Positions as two 32-bit values Or'd into a 64-bit long? Using some static methods. Not very OOP.

I'm entering the phase of the project where I feel the need to start from scratch as the project has developed fundamental problems, like memory usage and speed, and even the changes I can think of are so widespread, it will require alot of refactoring work.

That's why I've been looking toward other languages and platforms. However, simply moving to Groovy or Scala wouldn't help any - they still run in the JVM. And moving to .net/Mono seems to have performance and memory problems of their own. And I don't want to abandon non-windows.

------------------------------------------------------

As for sdlJava, I've read that it doesn't offer much of an improvement over Java2D. Except that Java2D doesn't hardware accelerate some operations, like alpha compositing.

I'm entering the phase of the project where I'm talking alot more than I'm coding. Worrysome.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4952
Moving Pictures
« Reply #64 on: January 26, 2012, 02:22:06 AM »
Interesting that you've already profiled that and found where a lot of the memory is going. Still, hundreds of thousands of 8 byte objects is still only maybe a couple of megabytes. Mind if, if you have any non-final methods on that class, it will probably add an extra 4 bytes for a vtable pointer. I bring this up because you said there are a lot of helper methods, and if even one of them is non-final, that vtable pointer will be needed.

Also, I doubt there would be much to gain by replacing those objects with strange packed integers. I would be a little surprised to see any real speed or memory gains (and might even expect some speed loss, depending on how things work out). The cost to clarity and maintenance doesn't seem justified there.


At the moment I'm kind of thinking maybe you should just bite the bullet and start refactoring the existing code. I know refactoring can often seem more daunting than just giving up and doing a rewrite, but refactoring is often the best thing to do. There is a lot to learn from refactoring attempts. Time spent refactoring usually means you better understand the problems you're now facing, and will have a better idea how to solve or avoid these problems in the future. I know it can be a bit of a hassle to actually have to really think about the mess of code you've just realized you've written, but there's also a lot to learn from exactly those types of problems. It's quite helpful to step back from your code once in a while, and forget about how it solves a problem, and instead consider what problem is being solved, and also why you choose to solve this particular problem. I find that last statement is not easy to fully appreciate until you've actually spent some time trying to refactor large projects.


It also good practice to learn how to modify code in small steps. Particularly if you want to work as a programmer. The people paying the bills (such as your salary) are generally not very receptive to the concept of basically throwing away everything they've paid you to develop, and then to continue paying you to develop entirely new stuff that won't be functional for quite some time. If you refactor, it might be that you end up replacing basically everything, but people paying the bills are generally more receptive to the concept of replacing things small parts at a time, so that the whole system remains functional throughout the transition. Plus, it's kind of fun trying to figure out how to replace certain parts of a system without breaking anything. It takes a lot of discipline though. You have to avoid getting sidetracked. It's very easy to try changing too much at once. Just because you've noticed something small and easy to fix while in the middle of making another change, doesn't mean you should fix it now.

I find when I end up refactoring existing code, the majority of my commits only touch about 10 lines at most. I generally strive for the smallest possible change, that's still meaningful, self contained, and doesn't break anything or reduce functionality. Additions of new code are sometimes bigger, but they're usually done in a stepwise manner, so new tested code gets committed, and then another separate commit will modify existing code to place the new code into the code path. You might also remove old code at such a point, but I usually don't do that until a later commit. It's nice to have a commit around in the middle where you can easily switch back and forth between old and new sections of code for testing and verification purposes.



Oh, and btw, with new HTML5 features, such as the Canvas object, that JavaScript joke might have a bit more seriousness to it these days than many of us would like to admit. There are already games being written in pure JavaScript that don't need browser add-ons or embedded applets to run. I still think JavaScript is a bit of a sick and twisted language, and certainly has some maintenance drawbacks, but people who are determined enough certainly seem to be able to do quite a bit with the language.
« Last Edit: January 26, 2012, 02:26:50 AM by Hooman »

Offline Marukasu

  • Full Member
  • ***
  • Posts: 110
Moving Pictures
« Reply #65 on: March 28, 2012, 09:00:06 AM »
This definitely seems like a promising remake.

I notice it's been a few months since your last posting on the forum...
I hope you plan on continuing the project, or passing it on :)