ReactToPush

[v6v]

As the title says, why does ReactToPush not work in HTML5?

The Datasheet says "No" and my game just hangs there because of a break in the script using IE's F12 developer tools.



Edit: additional information- my purpose is to create a sprite category that pushes itself out of the way of other instances in the same category, currently the end result is a group of sprites walking in a tandem line, something that runs great in the C# code but not in the HTML exported project. a good visualization would be soldiers walking in line.

Are there any alternative ways of going about that? I'm looking through the HTML datasheet and I'm noticing a good amount of the rules that would probably use reflection or passing by ref (JavaScript passes by reference automatically, right?) aren't supported or are just untested.

[bluemonkmn]

It just wasn't among the functions I thought critical enough to implement in the first iteration. I think the iotabuildit project implemented it, though. Can you get the implementation of reactToPush from http://hg.code.sf.net/p/iotabuildit/code/raw-file/408d42e6cd90/HTML/SpriteCustom.js?

[v6v]

Neat! I'm searching through that to find any other functions of interest.

[bluemonkmn]

If you want to see the whole project and all its source, you might want the whole SGDK2 file: http://hg.code.sf.net/p/iotabuildit/code/raw-file/408d42e6cd90/SGDK2/iotaBuildIt.sgdk2.

[v6v]

It seems that a Sprite's Priority has a huge effect on ReactTPush.

Why is that, bluemonkmn?

[bluemonkmn]

ReactToPush has never been the most reliable function. Instead of treating everything as equals it definitely has some bias in treating the sprites at the beginning of the list differently than those at the end. Since each sprite is moved only once relative to the others, sprites at the end are, I think, going to be more subject to the new positions of the sprites at the beginning while sprites at the beginning will be more subject only to the old positions of sprites at the end. It got really complicated and confusing and I kind of gave up after I got it "good enough" for my purposes. I wasn't prepared to implement a whole physics engine for one little function.

In conclusion, unless pushing sprites is really your goal, I would not recommend using ReactToPush for anything that could be done a different way.

[v6v]

I'm still interested in iotaBuildIt

I wonder, if I were to separate ReactToPush from ExecuteRules(), and process it only after ExecuteRules() were processed, woud it have any effect?

EDIT

A good amount of the rules aren't working as they should in Windows RT, so this may be why it's not working for me.

I'm trying to look into this to see what's going on, it doesn't seem like SGDK2.

[bluemonkmn]

It would be odd for Windows RT to be the only factor. The rules are Javascript, which you'd think would be the same on any platform. Although there might be browser differences in the JavaScript implementation. Have you tried running the game in the same browser version on Windows RT and Windows 7? Or it might have to do with the window size or input method -- are those different when you're running on Windows RT versus your other environment?

[v6v]

I've just tested ReactToPush in 4 browsers, it seems like it's giving me the same results in each one. Do you think ReactToPushback would work any better?

I've just ran IE's developer tools and looked in the console, it seems like there are a good amount of script errors that the browse r ignores that Visual Studio 2012 completely quits on.
These weren't visible to me until now. It's why I'm getting different behaviors in IE. There are a good amount of CustomObjects and LogDebugLabel rules that I've completely forgotten to suspend.

Window Size:

The scaling ratio that I'm using with the resizeView method (In another thread) negatively affects the scroll margin, and gives me the strange outline around the tile effect that I had with Neuro Project Ballio, which I had fixed by changing the rendering to "Linear"/"Nearest", but I'm not quite sure if the fix would be as easy in HTML.

In both browser and RT the canvas doesn't fill the screen immediately unless I add the resizeView after gameViewContext is originally defined...

Not as important:

I may just try my hand in the C# route rather than the HTML route, I'm having issues such as the game crashing whenever a new map is being loaded, or whenever too many sprites are on screen (Regardless of the exception that is automatically set to be thrown in SpriteCollection) and I'm averaging about 20 FPS. I'm not sure how memory is handled in HTML5, (I was told that the browser decides) and regardless of memory, it seems like a general performance issue anyways so I'm at wit's end.. it shouldn't be hard to get what I already have working.

Ever consider getting iotaBuildIt in Windows 8 bluemonkmn? The reason why I'm even bothering is because I hear there's a demand for good games in Windows 8, if developers hear about our forum's source control controlled project, it would definitely make some online geeky news article headlines. Give it an interesting touch interface and it could do really well.

[bluemonkmn]

ReactToPushback is not supposed to be an alternative to ReactToPush, but rather a piece of the implementation of pushing. See how it's used in iotaBuiltIt. I can't remember exactly how, but depending on whether the sprite generally pushes others or is pushed by others, I think it may call reactToPush and reactToPushback in a different sequence or something. The player spirite, for example, might only call reactToPushback, so that it doesn't get pushed except when the things it's pushing can't move any more.

I don't have any experience with scaling. None of the code is tested/designed for use with being scaled, so I can't say what needs to be done related to scaling.

Browsers are far too forgiving about errors... At least by default. I think there's an option to display a message about every scripting error that's turned off by default. You probably need to address all the errors before dealing with other problem behaviors that might be arising out of some of these errors.

I'm not sure what else to do with iotaBuildIt to get it noticed. I feel like it's still not "finished" enough to draw any good attention. Did you have any specific suggestion on what should be done with it related to Windows 8? I don't have Windows 8, BTW. I suspected that sgdk2 projects written in Windows 7 would work just as well on Windows 8. But I don't know.

[v6v]

Mhm, you're more than right bluemonkmn, mouse input is off as the view is scaled up and down.

iotaBuildit needs more people to work with it, and I'll be the first to apologize that I haven't put in enough time or effort to pitch my "impetus" to keep the wheel moving forward.
When I start to contribute, the first thing that I'll attempt to do is make it appealing mainly to tablet users by giving it an entirely touch screen focused base, for people who don't have keyboards.



You're right again, SGDK2 runs on Windows 8, but not under Metro status. (Unless you're using HTML5) OpenTK users and XNA users alike are scrambling across the forums to find a hotfix to get their games running under Metro, but it doesn't seem like there's any easy miracle line of code or build target that can change it. If push comes to shove and I believe it will given the above situation  , I'll look back into the Original SGDK2 to see how the DirectX is used, I'll stick to whatever Audio framework Microsoft offers now for developers since it's not as simple as using say... Audio under XNA.

I'm prepared to eat my foot in the case that I'm wrong, there may be a way to get it running immediately through metro without having to scrap OpenTK and Fmod.

As for Windows 8, universities offer it free BUT.... I'm in no way supporting piracy, but I managed to see something interesting on a YouTube video.

The same for Visual Studio 2012, on another YouTube video. I can't understand why it costs an *arm and a leg* for someone to want to be creative these days. Even something as simple as an Arduino can set you back 35 dollars, looking at the comprising parts costs way less, around $9.00.

I'm sure you can afford copies of the software, no doubt, but $500 dollars isn't feasible for some. In my situation at least.

[bluemonkmn]

Windows 8 discussion continued at http://gamedev.enigmadream.com/index.php?topic=1644.0.

[v6v]

Going to add this:

AddSpriteAtPlan is officially tested, and it says that lastCreatedSprite is undefined.

Should I change lastCreatedSprite to GeneralRules.lastCreatedSprite inside of the .js function?

[bluemonkmn]

Oops. Yes, that looks like the right correction. I have corrected it in subversion in SGDK2's code. I have not created a new SGDK2 release with that correction yet, though.

[v6v]

Anyone else working on a SGDK2 HTML5 project, when counters reach their limit, they loop back to the min value in JavaScript.

Similar to the ModulateAlpha/Red/Blue/etc.

bluemonkmn, can you add this to the HTML5 datasheet?

This should explain some strange behaviors relating to counters.

EDIT: That doesn't seem to be it either...? I'm not sure what's going on.