ID:1238445
 
Just wanted to say that the announcements page hasn't had a new post since last year. Everything is a reply which means we have to dig through posts to see anything and we have no idea if there is anything worth looking for. It would be nice if announcements weren't buried in replies. It's OK to have a new threads with reoccurring topics.

I check in often to look for significant updates and they just aren't visible.
^ this

Has been an issue for awhile now, so my advice .. keep on sifting through replies until you find something anything that's an update..
PopLava wrote:
Just wanted to say that the announcements page hasn't had a new post since last year. Everything is a reply which means we have to dig through posts to see anything and we have no idea if there is anything worth looking for. It would be nice if announcements weren't buried in replies. It's OK to have a new threads with reoccurring topics.

I check in often to look for significant updates and they just aren't visible.

I only found out about javascript function calling because I started panning for gold in them thar updates.
...and there is a couple posts from this year, I just overlooked them because posts from this year don't specify the year. These forum pages are so busy for some reason. No concept of read and not read or something.

a lot of interesting opportunities open up with browser communication.

Did they change something with javascript?
Sort of. You can call out to Javascript using output() now.

Format:

client << output(params,"browserid:functionName")


Params is a number of arguments for the JS function formatted via params2list.
Browserid would be the skin id of the browser.
functionName would be the name of the javascript function.

Then you just bootstrap a system using Topic() and some invisible links with a JS click event launcher, and you can call functions back and forth between JS and DM. It's pretty nifty.
That's been around for a while. :) I used it heavily in a lot of the BYOND based applications I wrote. Looking toward HTML 5 now. Only trick is to get BYOND clients into IE9 mode but then that could mess with their other BYOND experiences. We need the ability to toggle the IE version. BYOND could automatically toggle the version back when the game exits. I wonder if they would add a proc for toggling the IE version so we can better support HTML 5 games hosted in BYOND. Seems like BYOND might be able to benefit from having their own HTML 5 "engine" or the possibility of incorporating an existing one.
One way you could do it, is to just use Javascript and Topic() to tell DM their browser version gathered from JS. If IE7/8 are the default, fall back to another interface, or forcibly disconnect the client after telling them the system requires IE9.
Unfortunately, all embedded IE uses IE7 compatibility mode if it's at a version higher than 7 -- this is a limitation of IE itself and nothing BYOND can easily change.
I've already gotten HTML 5 "apps" to render in BYOND's browser and I even played the games. No problems. Required a reg hack to force IE9 mode rendering though.
Yeah, I've heard of registry hacks helping the problem; but this isn't something BYOND itself is going to do for a client, it's not BYOND's place to be fiddling with registry entries outside of its own.
I'm sure there are implications but mucking with registry is likely not one of them. Matter of compatibility and support. If developers can demonstrate value, "BYOND" will give it consideration.

I'm far removed from what it would actually take to support/implement HTML 5 and I have no idea how the business model works out but it feels like BYOND is in an interesting position to go after it from an IDE/Server aspect.

Let's say BYOND developers can easily get players into HTML 5 based games provided they have IE9. Tough sell but not too far of a stretch. What then? What can they do with it? I'm thinking out loud at this point. What could I do with it.

Multi-player HTML 5 games. Likely would struggle with any fast paced multi-player games but almost any other genre would be fine. Even RPG would work out ok.

Unprecedented special effects in a "BYOND" game. A lot of external resources which means lots of external chatter about using BYOND to develop and host HTML 5 multi-player games. We can utilize external libraries and tools while BYOND can help bring them all together and provide resources, tools, community, and lastly, more hosting options for light weight games that only require things like accounts, session states, high scores, and etc. Think of a 100% HTML 5 game that utilizes BYONDs infrastructure for hosting the game and providing a place for the game to store and retrieve information.

Massive client side processing benefits. All the heavy lifting gets done on on the client which is huge.

SVG. Canvas. Hardware Acceleration. Video. Sound. Benefits.

Likely generate a whole new wave of BYOND excitement and community effort.

MULTI-MAPS. You can have as many HTML 5 maps open as you want. Primary reason why I've been looking at it. One of my game concepts needs a large number of maps open at once.

Not claiming to know my stuff here at all but it seems really interesting.

I was always concerned about the open sourcness of it but if a large chunk of the game is on the server and just the rendering aspects or on the client, it seems reasonable. Half the code that we would end up using is open source anyway.





The issue is more the implementation strategy. As a for-instance, multiple maps carries a notable implementation change on the server, as much as it does the client.

What you'd be able to offload to the client via JS would also be kind of limited (but not without value, mind), as any actual game state changes have to go back as requests for the server to do so, leaving the client JS's use-cases to rendering local effects, and doing things like fetching client specific data to put into arguments of a procedure call (like say, x,y mouse locations).
Multi map is all about how you design the game. sessions, ticks, amount of information needing to go back and forth.

Yeah, it's largely dependant on networking performance for faster moving multiplayer games.

Checkers as an example would easily work out and I think I will attempt it as a prototype only to see what I can do with some basic html 5. I'm curious to know how many html 5 tools and resources are out there to help with development.
You were suggesting basically a front-end HTML5 client for the BYOND suite in that previous post I replied to, right?
Honestly, not sure what I'm suggesting at this point. Going to ramp up on it a little bit and see where I get.
In response to PopLava
PopLava wrote:
I'm sure there are implications but mucking with registry is likely not one of them. Matter of compatibility and support. If developers can demonstrate value, "BYOND" will give it consideration.

Compatibility and support are big ones, yes, but registry mucking is absolutely a concern. What you're suggesting would modify one of the more highly protected areas of the system registry, a place where most antivirus programs will freak out if an installer messes with it. It also would be changing something universal to the system, causing unpredictable behavior in apps that rely on the embedded browser (including, at this point, BYOND itself). It's on the order of modifying your home page in your installed browser or changing your system theme--users wouldn't want to deal with one program creating fallout for all the others.

Where HTML5 is likely to be the biggest advantage to us down the road is in creating a new browser client like our Flash client.
OK. Based on what I've read about the FEATURE_BROWSER_EMULATION key, it's scoped to just the specified application.

By defining dreamseeker.exe - DWORD 9999, it puts dreamseeker into forced IE9 mode and does not impact any other application.

It is specifically designed so application developers who host IE can force a specific rendering mode. As an example, AcrobatReader does this as does (did) applications like Quicken.

Obviously a concern for one game impacting another but that should be addressable in terms of checking the registry at game startup (only for games with a browser control) to make sure the game's preferred rendering mode is set. If the game does not specify a custom rendering mode but the registry has dreamseeker listed, you delete it.

It seems quite reasonable to me.
In response to PopLava
Ah, I was not aware of that; most of IE's registry settings are universal.

Of course, we'd have to retest the whole beta pager in this mode since it's being built with current limitations in mind.
You shouldn't have too much trouble anything in IE7/8 should work flawlessly in IE9 it's the other way round you have more issues well that's web/CSS wise.
I really have nothing constructive or positive to add here, but I just want to say, the fact that there's even 4 different versions of IE in the last few years is hilarious, and the fact that anyone cares about IE support is also... hilarious.

Long live Google Chrome FOREVER.

I am slightly drunk. I love you.
Page: 1 2