ID:259610
 
Zup, all, I've been gone for some time cause of school but I started thinking what would make BYOND cooler. First I would like it if you could play a flash game and host it so other people can watch you play it, and for it to be on Live! Also so when they join, not run their own game to get their own version. Another thing is that I have been workin on my big cousin's emulator(he's 17) I was wondering if there is a way to make the emulator playable on BYOND so that I can make custom roms like Chrono Trigger to be played with lots of people. Another thing I would like to see is dantom make a delagger. Sorry for all the requests but I know you guys like suggestions.
Yugi Moto wrote:
First I would like it if you could play a flash game and
host it so other people can watch you play it...

Can be done already using byondcgi and the HTMLlib... just put a Flash game in the browser, and away you go!

I was wondering if there is a way to make the emulator
playable on BYOND so that I can make custom roms like
Chrono Trigger...

Well...having BYOND emulate something that it can do itself just as good, if not better, seems kinda silly to me...

Another thing I would like to see is dantom make a delagger.

This is not a fault of BYOND. Lag is caused by things beyond BYOND's control, bad net connection, bad code optimization, or a combination of these things... these are things a program cannot fix by itself...
Yugi Moto wrote:
Zup, all, I've been gone for some time cause of school but I started thinking what would make BYOND cooler. First I would like it if you could play a flash game and host it so other people can watch you play it, and for it to be on Live! Also so when they join, not run their own game to get their own version.

It's called the browser window.

Another thing is that I have been workin on my big cousin's emulator(he's 17) I was wondering if there is a way to make the emulator playable on BYOND so that I can make custom roms like Chrono Trigger to be played with lots of people.

BYOND is not an emulator. Why do you want it to be one?

Another thing I would like to see is dantom make a delagger.

Okay then! How do you propose we break the laws of physics?

Sorry for all the requests but I know you guys like suggestions.

Only if they make sense.
In response to Garthor
Are you reffering to flash as .swf files? if so you can already make flash MUDS with macromedias flash server program that comes with the MX suite. I dont know about integrating it into byond however...
In response to digitalmouse
Another thing I would like to see is dantom make a delagger.

This is not a fault of BYOND. Lag is caused by things beyond BYOND's control, bad net connection, bad code optimization, or a combination of these things... these are things a program cannot fix by itself...

It is true that no program can fix lag, However some lag is the fault of Byond. Thus byond can be improved, here are a few ways that i know can help.

1. Code optimization in byond itself
2. replacing bit-blt with something that can handle a larger load (DX, Opengl)
3. data stream compressing for the net code (compressing of the data before sending it can cut back on a lot of network lag)
4. some client side processing.

Improving and/or changing any of things can make byond run much better.

In response to Xzar
Xzar wrote:
It is true that no program can fix lag, However some lag is the fault of Byond. Thus byond can be improved, here are a few ways that i know can help.

1. Code optimization in byond itself

I'd be willing to bet Dantom have already optimized the snot out of the internal code.

2. replacing bit-blt with something that can handle a larger load (DX, Opengl)

Moving to DirectX would be a good start.

3. data stream compressing for the net code (compressing of the data before sending it can cut back on a lot of network lag)

I'm not sure if this is already done or not.

4. some client side processing.

It'd be nice to be able to mark a proc as client-run and have that sent as data to the client. Any time it ran it would need access to some other vars, though, so there'd have to be some way to send those over.

I'd personally like to see drawing optionally implemented as a client-side proc. Such a thing could potentially pave the way for 3D games, action isometric, wireframe, and more.

Lummox JR
In response to Lummox JR
4. some client side processing.

It'd be nice to be able to mark a proc as client-run and have that sent as data to the client. Any time it ran it would need access to some other vars, though, so there'd have to be some way to send those over.

I'd personally like to see drawing optionally implemented as a client-side proc. Such a thing could potentially pave the way for 3D games, action isometric, wireframe, and more.

Lummox JR

Yea, I fully agree with that.
In response to Lummox JR
Lummox JR wrote:
Xzar wrote:
2. replacing bit-blt with something that can handle a larger load (DX, Opengl)

Moving to DirectX would be a good start.

I have to wonder if this really affects lag at all. Yes, the current Windows drawing functions are relatively slow, but then we're only talking about 10 fps here. If Doom could get 30 fps on a 66 MHz 486, surely 10 fps is nowhere near the bottleneck on modern hardware? I'd bet any slowdown from this is lost in the noise, but maybe someone with actual Windows graphics programming experience can lay the smackdown on me and set me straight.

That said, I vote for OpenGL as an eventual successor to the current drawing method. It's cross-platform, and if I didn't hold out a tiny amount of hope that BYOND will one day have a gui outside of Windows, I probably wouldn't be here.

3. data stream compressing for the net code (compressing of the data before sending it can cut back on a lot of network lag)

I'm not sure if this is already done or not.

My limited understanding, which could be very wrong, is that it uses gzip compression for resource transport and run-length compression for game messages. While run-length isn't anything great, I'd bet most message packets are small enough that any better compression algorithm would be wasted on them (and quite possibly would do worse). Messages are generally sent continuously as small packets to update game status.

4. some client side processing.

It'd be nice to be able to mark a proc as client-run and have that sent as data to the client. Any time it ran it would need access to some other vars, though, so there'd have to be some way to send those over.

This I would love. Too bad they didn't think of it 6 years ago and design it into the system from the start. As it is now, this would undoubtedly require a major redesign of significant portions of the runtime engine. Don't hold your breath until BYOND becomes financially self-sufficient.

Some good thoughts, though.
In response to Air Mapster
That said, I vote for OpenGL as an eventual successor to the current drawing method. It's cross-platform, and if I didn't hold out a tiny amount of hope that BYOND will one day have a gui outside of Windows, I probably wouldn't be here.

I'll make a vote for OpenGL too, but only because I have an affinity for it -- it has nothing to do with anything except personal taste. =)


It'd be nice to be able to mark a proc as client-run and have that sent as data to the client. Any time it ran it would need access to some other vars, though, so there'd have to be some way to send those over.

This I would love. Too bad they didn't think of it 6 years ago and design it into the system from the start. As it is now, this would undoubtedly require a major redesign of significant portions of the runtime engine. Don't hold your breath until BYOND becomes financially self-sufficient.

I agree: client-side is one of the most necessary things, but also one of the least likely things... or, at least, in the immediate future.

Something that would probably cull out a ton of lag would be the ability for the client to maintain its own set of data, then adjusting itself appropriately when the server sends a new update. In layman's term, client-side prediction. The ultimate value of this is that the client doesn't have any say in what actually happens -- the client runs code to make educated guesses and then the server tells it whether those guesses were correct or not.
In response to Lummox JR
3. data stream compressing for the net code (compressing of the data before sending it can cut back on a lot of network lag)

I'm not sure if this is already done or not.

Occasionally you'll see BYOND BUG: Zstream Compression Failure (or something along those lines)... so I'd say yes, the network data is compressed.

-AbyssDragon
In response to Xzar
Wow, I was grounded I couldn't check the forum...I don't get what you are saying...I guess I don't know nerd talk (no offense, nerd talk is computer talk to my cousin who is making the emulator, but for some strange reason he is not a nerd but know a lot...)
Yugi Moto wrote:
Zup, all, I've been gone for some time cause of school but I started thinking what would make BYOND cooler. First I would like it if you could play a flash game and host it so other people can watch you play it, and for it to be on Live! Also so when they join, not run their own game to get their own version. Another thing is that I have been workin on my big cousin's emulator(he's 17) I was wondering if there is a way to make the emulator playable on BYOND so that I can make custom roms like Chrono Trigger to be played with lots of people. Another thing I would like to see is dantom make a delagger. Sorry for all the requests but I know you guys like suggestions.

Delagger = no no
Emulator = no no
playing other games made in a different language = no no
In response to Maz
Delagger = no no
Emulator = no no
playing other games made in a different language = no no

More accurately,

Delagger = impossible
Emulator = impossible
Playing other games made in a different language = impossible. =P
In response to Spuzzum
Spuzzum wrote:
Emulator = impossible

Depends on what you emulate. Done right, you *could* emulate the C64 *and* C64-BASIC in DM, and it would be quite a challenge emulating the sprites and sounds of that system.
In response to digitalmouse
digitalmouse wrote:
Spuzzum wrote:
Emulator = impossible

Depends on what you emulate. Done right, you *could* emulate the C64 *and* C64-BASIC in DM, and it would be quite a challenge emulating the sprites and sounds of that system.

I still lump that in the realm of impossible -- especially when you take into consideration that BYOND is incapable of loading external files in any other format than icons, sound effects, savefiles, or ASCII.
In response to Spuzzum
I still lump that in the realm of impossible -- especially when you take into consideration that BYOND is incapable of loading external files in any other format than icons, sound effects, savefiles, or ASCII.

You just need to convert the ROM format to something BYOND can read.
In response to Theodis
Theodis wrote:
I still lump that in the realm of impossible -- especially when you take into consideration that BYOND is incapable of loading external files in any other format than icons, sound effects, savefiles, or ASCII.

You just need to convert the ROM format to something BYOND can read.

Which requires external programming knowledge. Might as well just write a program in that external language to use the darned ROM. ;-)
In response to Spuzzum
Which requires external programming knowledge. Might as well just write a program in that external language to use the darned ROM. ;-)

Well when a ROM is dumped it is in some way changed from its original form which is seperate from the emulator so why not just use the original instead of an emulator :P?
In response to Theodis
Theodis wrote:
Which requires external programming knowledge. Might as well just write a program in that external language to use the darned ROM. ;-)

Well when a ROM is dumped it is in some way changed from its original form which is seperate from the emulator so why not just use the original instead of an emulator :P?

Touché.
In response to Theodis
Theodis wrote:
I still lump that in the realm of impossible -- especially when you take into consideration that BYOND is incapable of loading external files in any other format than icons, sound effects, savefiles, or ASCII.

You just need to convert the ROM format to something BYOND can read.

A problem there - C64 programs are not ROM files, but they are a unique format (at least the compiled/machine language programs are). But BASIC files can be just text, and could be opened/written/saved as normal ASCII files (actually, the C64 used 'Commodore ASCII', which is a little different, but there are converters available for DOS/Windows machines). Then it is just a matter of building a BASIC interpreter to parse the programs... Of course it would be a pain to implement C64 sprite graphics (although I would imagine that pixel movement could be used), speed would suffer, and you could not use custom tricks (like kernel calls) to run programs... in fact you might be just limited to using plain old text-based programs. Luckily there are several very good C64 emulators out there for free, so making one in BYOND is moot.

My point was that it *could* be done - whether or not it would be practical to to do so is another matter...