Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - durnurd

Pages: [1] 2 3 ... 83
Game Development Artistry / Re: Walking Sequences
« on: 2013-03-27, 08:06:23 AM »
And about the C# video on neutral networks: the guy reminds me of Sheldon in Fun with Flags!!! Haha!  ;D


Help, Errors, FAQ / Re: JIT Debugging
« on: 2013-03-04, 04:45:53 PM »
You need to check it out using Subversion:

Or you can download a 7z copy of the source that was made manually at some point, which probably has (but is not always guaranteed to have) the latest code:  (use the "src" link)

General Discussion / Re: SubLists for Graphics and Framesets
« on: 2012-10-25, 05:04:23 PM »
I would also vote for globally unique names regardless of the path leading up to them.  As #Sharp mentioned, it would make things simpler.  Then some day, you may be able to make a change to the program to include a proper UI and data structure change so that the names don't actually include slashes, and everything will still work correctly.

Projects / Re: Project Paradigm
« on: 2012-09-14, 06:36:53 AM »
Do you plan on having 250 sprites on one screen on one server all at once?  Because every client doesnt need to know the location of every sprite, just the near by ones.

Also, it's highly unlikely that you will be able to have hundreds or even dozens of real-time, persistent connections into one server at a time.  Even large scale MMOs try to keep the load on any one server down, and unless you have your own rack of dedicated servers with a high-density connection to the Internet backbone, the server would probably lag immensely or perhaps just melt into a sad puddle of silicon and wires on the floor.

Moral of the story: 250 or more sprites is fine, but not all on one screen simultaneously.

Projects / Re: Project Paradigm
« on: 2012-09-10, 08:43:35 PM »
My example was contrived, yes.  Your expansion on the idea is a better example: Only send data for sprites that moved; in the case of simple x,y coordinates, it's okay to send the complete state every time it changes.  But if you're relying on specific animation sequences or hit boxes, or more data than just x,y coordinates, you will want to send deltas only, accumulating the data you need to send until packets are acknowledged.  If the lag is considerable, it may make sense to eventually just refresh everything, fetching the world state from the server (or "authoritative client") and resetting everything from there.

Projects / Re: Project Paradigm
« on: 2012-09-10, 05:36:15 PM »
You can make reliable connections on UDP the same way TCP does, using ACKs and packet numbers to ensure full packet delivery in the correct order.  The difference is that you can make it more efficient than TCP because TCP must ipso facto be generalized for any purpose and therefor is inefficient when you know more specifically what you're sending.

There are plenty of things you can do with this in mind.  For example:

If you can get away with it, only sending deltas can additionally speed up data transfers considerably.  By that I mean determine only what changed from the previous transmission to this one and send only that data.  For example, the player moves horizontally X pixels.  This is all the remote client needs to know.  Other data, such as Y position, are not necessary

You can keep track of remote data loss and account for that by sending bigger deltas instead of re-sending dropped packets.  For example, the player moves X pixels horizontally.  It then moves Y pixels vertically for the next transmission, and finally Z pixels vertically for the next.  The naive approach sends each packet (X,Y,Z) sequentially.  If any packet is not acknowledged, it, and each packet after, are re-sent.  Rather than simply sending the three packets with deltas X, Y, and Z, hoping each arrives, you could send each packet as (X), (X,Y), (X,Y+Z), accumulating deltas until you receive acknowledgement of receipt of any of those packets, then reset the delta from there.  For example, if you receive acknowledgement of receipt of the packet containing the data X, then your next packet only needs to send (Y+Z) instead of (X,Y+Z).  With this approach, you definitely need to keep track of packet numbers.  That would be how you specify what the delta refers to.

In our previous example, packet 1 would send X, referring to a base NULL packet.  Without receiving acknowledgement of receipt of packet 1, packet 2 would send (X,Y), referring to the same base NULL packet.  Then you receive acknowledgement of packet 1.  Then packet 3 would send (Y+Z), referring to a base packet 1 instead of NULL.

You can use interpolation on the remote client.  For example, we know the player's previous velocity.  Assume they keep going on that trajectory until we are told otherwise.  Then update with the actual position based on the data received.  You would also need to make sure your interpolation doesn't get skewed by a quick change of position due to an updated actual position.

Projects / Re: HTML5 TechnoVenture
« on: 2012-06-05, 05:46:38 PM »
Unfortunately, I do not have that project any more.  But if I recall correctly, there was very little I needed to do to the project to get it to work.  Yes, you can see the progress of getting it to work here:

That looks like it outlines everything I had to do to get things working.

Help, Errors, FAQ / Re: Maps, Maps, Maps.
« on: 2012-06-05, 05:35:46 PM »
Well, the code I provided was inlined to make it simpler to express.  It's plenty easy to do without any extra assemblies or Linq.

Code: [Select]
List<Type> maps = new List<Type>();
foreach (Type t in typeof(MapBase).Assembly.GetTypes())
    if (t.IsSubclassOf(typeof(MapBase)))

But obviously, there are other solutions, as you've found.

Help, Errors, FAQ / Re: Maps, Maps, Maps.
« on: 2012-06-05, 06:51:03 AM »
I don't recall if there is such a list, but you can use this to create such a list.
Code: [Select]
typeof(MapBase).Assembly.GetTypes().Where(type => type.IsSubclassOf(typeof(MapBase)));

Projects / Re: HTML5 TechnoVenture
« on: 2012-06-05, 06:46:21 AM »
Anybody feel free to take it and run with it, wherever it goes. I just don't have the time/motivation to actually complete the prototype, profile the code, and make levels for it. If you get rich and/or famous, I claim 1% of said riches and fame :)

If it's just the retro-style game you're after, this is based on another SGDK2 project which runs natively and had a more complete set of features, and several completed levels.  That's based on an actually retro game, based on an even retroer game for the Amiga.  I believe I've already posted that one somewhere in the project repository, although I can't be certain...

Help, Errors, FAQ / Re: New user on the block
« on: 2012-06-04, 06:07:34 AM »
Mobile is, in fact, one place where HTML5 is well-implemented. Even across all platforms, compatibility is pretty well guaranteed. I have working HTML5 SGDK2 projects implemented on my iPod, in fact.

Projects / Re: HTML5 TechnoVenture
« on: 2012-06-04, 06:03:19 AM »
No plans to do anything with it, really.  I just had it sitting around collecting dust, and I didn't want it to go to waste.

I never noticed any lag either, with my previous computer or my new one. I suppose I could do some profiling.  Although I didn't plan on do anything else with it.

Projects / HTML5 TechnoVenture
« on: 2012-06-02, 11:25:47 PM »
Since I had this laying around and I wasn't doing anything with it, I thought I'd share it.  It's a port of the TechoVenture project that runs on HTML5. This is just a prototype, with pieces to show off the various functions. Dying is not implemented at the moment though.

I assume you mean you don't want to use a separate windows form, seeing as how the text box and the window you are slapping it on are bothe in the windows.forms namespace. I'm not familiar with the inner workings of the OpenGL view, but I would say yes, you can just create a textbox and add it as a child to the root form. Just make sure you're doing so on the main UI thread, otherwise hilarity ensues.  Or crashing. One or the other. Probably the other... It's the other.

Projects / Re: The Crowdsourced Game
« on: 2012-05-09, 06:25:51 AM »
I'm not suggesting getting rid of the Export to HTML option, but not having to use it while testing would be much simpler.  It would just always export each js file separately and the images embedded.  It could go into a temporary location. Then when you're ready to distribute it, you could use the export option.

As for a virtual, I have recently used Virtual Box.  I think the part you may have to deal with though, is installing an OS.  It may not be worth the effort...

Pages: [1] 2 3 ... 83