ID:265362
 
I switch back and fourth so rapidly...I just can't decide on ONE game to make...x_X
Anyone find a care fur the "swithing rapidly between games" disease?
Hell Ramen wrote:
I switch back and fourth so rapidly...I just can't decide on ONE game to make...x_X
Anyone find a care fur the "swithing rapidly between games" disease?

Yep! Just create one engine, but have it data-driven as much as possible. That way you're working on two(or more) games at once! After you're done, it's time to fill in content, customized code for each game, etc.
In response to Jon88
Jon88 wrote:
Yep! Just create one engine, but have it data-driven as much as possible. That way you're working on two(or more) games at once! After you're done, it's time to fill in content, customized code for each game, etc.

Yeah, but, I switch back and fourth to new and old games frequently, which use different engines.
Hell Ramen wrote:
I switch back and fourth so rapidly...I just can't decide on ONE game to make...x_X
Anyone find a care fur the "swithing rapidly between games" disease?

Decision is the cure. Pick a game that you like and stick with it.

Alternatively, you could start up a new game and stick with that.
In response to Wizkidd0123
Wizkidd0123 wrote:
Alternatively, you could start up a new game and stick with that.

Don't listen to him! He's just trying to make it worse! =P

I have a folder - actually, two folders - full of abandoned projects. Most of them were only worked on for one day, or two at most. Most of them will never get touched again. But that's okay; if I gave up on them that easily, they probably wouldn't have turned out to be very good anyway. =)
I have a ton of games that I've worked on. I always work on them until I get to a point where Dream Seeker just isn't powerfull enough to do everything I want it to... then I'm forced to consign it to the folder of abandoned games and misfit toys. They all work... they just do so much every 1/10 of a second that it becomes slow as molasses.
In response to IainPeregrine
Molasses taste good in cookies. :P
Well, I guess I'll move them all into one folder when I abandon them, and maybe go back to them oneday. I dunno'.
In response to Crispy
Ive got 119 total projects on this computer, which I've only had for a few days over thirteen months. That does include games, demos, libraries, and testing projects, but that is still about one new project every three days.

I need focus...
In response to IainPeregrine
IainPeregrine wrote:
I have a ton of games that I've worked on. I always work on them until I get to a point where Dream Seeker just isn't powerfull enough to do everything I want it to... then I'm forced to consign it to the folder of abandoned games and misfit toys. They all work... they just do so much every 1/10 of a second that it becomes slow as molasses.

This is a design issue.

Point being: if you implemented this game in C++, it'd do so much every 1/10 of a second that it becomes slow as syrup. Not as slow as molasses, because there's no DM interpreter overhead, but syrup is still very slow. =P

The key in any software development is to compromise and make sanity decisions which allow your processor to do a minimum of work and still provide a maximum visible return to the players.

For example, say I have a delicately placed ecosystem with 25,000 animals who all have realistically modelled intellectual processes, and who all find each other and group together for protection, breeding, etc. On the other hand, say I have a system which randomly generates 2500 spawn points across the world, and each spawn point randomly generates 5-15 animals in a big herd when the player comes close to them, then deletes those animals when the player goes out of range.

The end result to the player? In either case, the player comments, "Wow, this world is full of wildlife!" But in the latter case, the world is not actually full of wildlife. It just seems that way.

Remember: abstraction, abstraction, abstraction!
In response to Spuzzum
This is a design issue.

Point being: if you implemented this game in C++, it'd do so much every 1/10 of a second that it becomes slow as syrup. Not as slow as molasses, because there's no DM interpreter overhead, but syrup is still very slow. =P

I do not wish to sound condesending, but please do not act as though I do not know what I'm talking about. I do program in C++, and I can display a 256x256 block of pixels every tenth of a second (that's 65536 pixels, plus all the code which determines the image I'm outputting) with no big problem. In DM, I can't output a 13x11 grid of /ojbs every 'tick' without extreem system lag. The difference is that in C++, the code is only concerned with outputting pixels to the display, whereas in DM, a data object added to the client.screen list needs to be of /atom/movable type, which includes a lot of overhead unrelated to display output (map positioning, movement, stat, etc.). Dynamically creating a 13x11 grid of /atom/movables for each client (and I don't care how much fancy instance recycling you do) involves to much overhead for DS to handle. I don't like to come across strongly, but I don't like people acting like I don't know what I'm talking about. I've been coding for years, and I know how to read a client's behavior.
In response to IainPeregrine
If you tried to create and destroy 1430 objects per second in C++, it would still be slow. =P

Point being: Why do you need that many objects? Find a better way. Or only create the initial 143 objects and just change their icons. Maybe even use overlays with pixel offsets to minimize the number of objects (though I don't know if that would actually be faster; quite possibly not).

If all of the above fail, then I guess you're allowed to give up. ;-) BYOND was really intended for only certain types of games... trying to do 3D fast enough to be playable, for example, is a lost cause. Use Python! (Or C++ if you really must... ;-P)

Nobody's questioning your ability (though there's no need to react so hostilely; how are we supposed to know how long you've been programming for, hmm?) ... we're just pointing out the obvious. =)
In response to Crispy
If you tried to create and destroy 1430 objects per second in C++, it would still be slow. =P

That's the point, I wouldn't have to create or destroy anything excepting one text string. The pre-existing objects' properties are converted into a set of numbers (most often hexidecimal) and appended to a text string. Those numbers represent colors when sent to the display. The result is a display generated by one text string. All images in my (non-byond) games are only a series of numbers arranged in an ordered fashion. One text string is certainly less overhead than 1430 /atom/movables, at least that has been my experience.

though there's no need to react so hostilely;

True, you have my appology. However, Seeing to many new people get shot down with "no usr in proc. ungh." posts (most of the time when usr wasn't the problem, or was even perfectly acceptable in that usage) will make you like that. The arrogance of many of this board's users astounds me, and awakens my curmudeonry.
In response to IainPeregrine
though there's no need to react so hostilely;

True, you have my appology. However, Seeing to many new people get shot down with "no usr in proc. ungh." posts (most of the time when usr wasn't the problem, or was even perfectly acceptable in that usage) will make you like that. The arrogance of many of this board's users astounds me, and awakens my curmudeonry.

*grins* If it helps, I'm particularly non-arrogant, in all matters excepting world domination. =) (However, admittedly, I am something of an elitist recluse... arrogance isn't quite the same...)

I tend to adhere to Guy T.'s excellent philosophy: "implied smilies". If, at any time you read a sentence and it sounds hostile, just assume that they neglected to include a smiley on the end. It works wonders.
In response to Spuzzum
Spuzzum wrote:
I tend to adhere to Guy T.'s excellent philosophy: "implied smilies". If, at any time you read a sentence and it sounds hostile, just assume that they neglected to include a smiley on the end. It works wonders.

Wow, I've been doing that for years! My parents hate it, though. =\
In response to Flick
I have about 13, most of which I have released.
In response to YMIHere
YMIHere wrote:
Wow, I've been doing that for years! My parents hate it, though. =\

What's their keys?
In response to IainPeregrine
IainPeregrine wrote:
I do not wish to sound condesending, but please do not act as though I do not know what I'm talking about. I do program in C++, and I can display a 256x256 block of pixels every tenth of a second (that's 65536 pixels, plus all the code which determines the image I'm outputting) with no big problem. In DM, I can't output a 13x11 grid of /ojbs every 'tick' without extreem system lag.

For the record, 13x11 tiles is 146,432 pixels, roughly 2.2 times the size of a 256x256 image. The size isn't really at issue, though.


The difference is that in C++, the code is only concerned with outputting pixels to the display, whereas in DM, a data object added to the client.screen list needs to be of /atom/movable type, which includes a lot of overhead unrelated to display output (map positioning, movement, stat, etc.).

There is quite a bit of overhead with creating a new atom, but only when the atom is created. The simple existence of the data does not slow down display. The examples you listed produce no additional overhead for a pure client screen obj. Map position should be null and remains null, they do not move, and Stat() is not processed for them. (The default behaviour is that Stat() is only called for a client's mob. For more info on that, read How Stat Panels Work from my "Guide to Verb and Stat Panels".)

The lag is actually the fault of BYOND's display code and has nothing to do with the extraneous data generated by them being /atom/movable. If you host through Dream Daemon and connect from another machine, you'll be able to see that it is not server lag from tracking the data. It is client lag from displaying it.

The way it is handled, it would be no faster if they were images. I've discussed it with Lummox JR, whose intimacy with that segment of the Dream Seeker code is second only to Dan. It is worst in Windows XP with full hardware acceleration and 32 bit color because BYOND currently uses bitblt. If you happen to be using that OS, you can speed things a little by turning down the hardware acceleration and color depth in your desktop settings.

BYOND will hopefully get an overhaul to OpenGL in version 4.0. The BYOND 4.0 teaser I saw long ago featured freestanding interface graphics that are not part of the map. We may be able to embed the HUD backdrop in the interface and only use client.screen for interactive elements (i.e. things you can click on.) The interactive elements are ultimately why client.screen uses atoms instead of just images anyway.


Dynamically creating a 13x11 grid of /atom/movables for each client (and I don't care how much fancy instance recycling you do) involves to much overhead for DS to handle.

It is needlessly wasteful to create 143 atoms for each client. It has nothing to do with "fancy instance recycling". You only need one instance of atoms in the HUD backdrop, which you can show to each client as they connect. The only unique atoms required for each client would be for individual display features like meters or dynamic text.


I don't like to come across strongly, but I don't like people acting like I don't know what I'm talking about. I've been coding for years, and I know how to read a client's behavior.

I don't doubt your abilities, but you're making assumptions that aren't entirely accurate. Talk to the development team and gather more facts about the client. If you see Lummox JR online, ask him about the client screen slowdown. I'm sure he'd be willing to answer your questions and explain things in as much detail as you like.
In response to Shadowdarke
Ah, now your speaking my language.

It is needlessly wasteful to create 143 atoms for each client.

No instance can have multiple separate (one for each client) screen_locs (if there is, there's no mention of that feature in the reference).
Therefore, in a game in which the 'map' is dynamically generated to be unique for each player, it becomes nessesary to create all of the display elements (including an X by Y grid of 'turf' like 'map' elements) to be displayed to that user (though the argument can be made that you only need to creat new elements at client.New(), but I would disagree).

For the record, 13x11 tiles is 146,432 pixels, roughly 2.2 times the size of a 256x256 image. The size isn't really at issue, though.

Good point. I'm an 8bit programmer, and use small icon mode, so I often forget that DM icons are 32x32 pixels. If you assume the tiles I'm refering to are 16x16, you'll see that a 13x11 grid would render an image smaller than 256x256. My mistake.

The examples you listed produce no additional overhead for a pure client screen obj

DS must at some point check to see if any /atom/movable are actually moving. Even if no /atom/movable are moving, it still must take processor time checking these different aspects of what it is to be movable, and then do nothing. However, you did call my bluff on Stat() (I was kinda hoping someone would :D), as that is client initiated. If you wish to tell me that all movement of everything on the map is also client initiated (in one way or another), then I'll believe that, but all the systems I've seen the code for work by looping through an array and acting based on the state of the object.

The lag is actually the fault of BYOND's display code and has nothing to do with the extraneous data generated by them being /atom/movable. ... The way it is handled, it would be no faster if they were images.

Ah, thank you. This is what I asked about in a previous thread.

BYOND will hopefully get an overhaul to OpenGL in version 4.0.

I, for one, will welcome that.

It is needlessly wasteful to create 143 atoms for each client. It has nothing to do with "fancy instance recycling". You only need one instance of atoms in the HUD backdrop, which you can show to each client as they connect. The only unique atoms required for each client would be for individual display features like meters or dynamic text.

HUD? Personally, I don't like the word. What I'm talking about here is completely bypassing the regular way DS treats the map, and creating your own output using the client.screen variable. In thus a manner, I can derive everything in my game from /datum, and never have to deal with the atomic system (except when packaging /objs for display to the client; hence the reason for my gripe). As is apparent, this goes far beyond a couple meters or dynamic text.

I don't doubt your abilities, but you're making assumptions that aren't entirely accurate.

True. I can only "read a client's behavior" to try and tell the way it was coded, ie. I cannot view the source code. Thus, I have to make an hypothesis, and hope that people can show me where I've gone wronge. However, even with all the explanations I've received, I still don't see how any of them can justify the statment "This is a design issue," when they all seem to confirm that the problem is DM being under powered (ie. the subject of my original post, and it's responce).

I really do hate to come accross strongly, and in most forums I belong to I'm know as a very easy going guy, so I'm sorry if this topic, or my manner of presenting it, causes a bit of a stir. Also, I don't want to take this thread entirely off course, but I am enjoying this conversation. Therefore, if a moderator would like to splite this thread into two separate topics, that would be appreciated.
In response to IainPeregrine
IainPeregrine wrote:
It is needlessly wasteful to create 143 atoms for each client.

No instance can have multiple separate (one for each client) screen_locs (if there is, there's no mention of that feature in the reference).

No, but I did put in a request for it in Post [link]. ;)

Therefore, in a game in which the 'map' is dynamically generated to be unique for each player, it becomes nessesary to create all of the display elements (including an X by Y grid of 'turf' like 'map' elements) to be displayed to that user

If you are overriding the entire map display through screen objs, you might get a performance boost by using a separate section of the map for each client and putting the client's individual display there. Client screen is much slower than regular map display because the screen_loc is parsed each drawing cycle (though I believe Lummox cleaned it up some a few versions back). You'll even be able to place things there as image datums instead of objs. :)



DS must at some point check to see if any /atom/movable are actually moving. Even if no /atom/movable are moving, it still must take processor time checking these different aspects of what it is to be movable, and then do nothing. However, you did call my bluff on Stat() (I was kinda hoping someone would :D), as that is client initiated. If you wish to tell me that all movement of everything on the map is also client initiated (in one way or another), then I'll believe that, but all the systems I've seen the code for work by looping through an array and acting based on the state of the object.

Movement is event driven in BYOND. To my knowledge, the only internal mechanism that loops through all datums is the garbage collector. Tom or Lummox could give you more info on that.


It is needlessly wasteful to create 143 atoms for each client. It has nothing to do with "fancy instance recycling". You only need one instance of atoms in the HUD backdrop, which you can show to each client as they connect. The only unique atoms required for each client would be for individual display features like meters or dynamic text.

HUD? Personally, I don't like the word. What I'm talking about here is completely bypassing the regular way DS treats the map, and creating your own output using the client.screen variable. In thus a manner, I can derive everything in my game from /datum, and never have to deal with the atomic system (except when packaging /objs for display to the client; hence the reason for my gripe). As is apparent, this goes far beyond a couple meters or dynamic text.

I use the HUD term when discussing the use of client.screen to display suplemental information over the map. What you're describing does go far beyond that. As I mentioned above, you might find map based display much faster than client scrren displays.


I don't doubt your abilities, but you're making assumptions that aren't entirely accurate.

True. I can only "read a client's behavior" to try and tell the way it was coded, ie. I cannot view the source code. Thus, I have to make an hypothesis, and hope that people can show me where I've gone wronge. However, even with all the explanations I've received, I still don't see how any of them can justify the statment "This is a design issue," when they all seem to confirm that the problem is DM being under powered (ie. the subject of my original post, and it's responce).

My projects also tend to push the limits of BYOND, so I know where you're coming from. It never hurts to hear other developer's input on how to improve your systems. (Constructive criticism, of course. I'm not talking about the random fellows who wander in spouting copy and paste code they don't really understand.) Spuzzum might have some ingenious system for client displays that neither of us have dreamed up yet. I often bring bottlenecks in my systems to others for their input. If it turns out to be a BYOND client issue, the development team need to know people are hitting that boundary or they'll never consider changing it.


I really do hate to come accross strongly, and in most forums I belong to I'm know as a very easy going guy, so I'm sorry if this topic, or my manner of presenting it, causes a bit of a stir.

No worries. I was concerned you might have taken offense at my post. I'm very glad you didn't. :)
In response to IainPeregrine
True. I can only "read a client's behavior" to try and tell the way it was coded, ie. I cannot view the source code. Thus, I have to make an hypothesis, and hope that people can show me where I've gone wronge. However, even with all the explanations I've received, I still don't see how any of them can justify the statment "This is a design issue," when they all seem to confirm that the problem is DM being under powered (ie. the subject of my original post, and it's responce).

It still is a design issue. ;-)

BYOND simply wasn't designed to individually process client screens on the server end. Heck, no language that I know of can decently handle server-side graphics. =)

Until BYOND gets the advantage of client-side programming (and thus gets clients running their own interpreters while games are running), totally overhauling the screen and replacing it with your own routines just isn't practical. The same would likely be true if you were trying to do server-side drawing in C++, then transmit the finished screen surface to the client (not the same concept, admittedly, but it's close).

It's not so much a matter of DM/BYOND being underpowered as it is a matter of making your game too powerful for the language to support. =)
Page: 1 2