Setting PIXI to fullscreen?

[achexi]

I'm not really asking for fullscreen in a sense. I've made the mistake of creating a game at [1024,768] size with huge textures and now after compressing them with things like tinypng, adding culling etc (trying to make my game as efficient as i can) I'm still not happy with its performance which is obviously the result of texture size (things like [3000,768] per texture)

 

So here's my issue it would be great to hear your opinions:

 

I require (if possible) the game to be running at [1024,768] so would simply setting the pixi canvas to something like [640,480] (still 4:3), resizing all my textures to fit in 640 480 and scaling the screen through html be more efficient than what I have now? Would it still look anywhere near as good? If else then is there a way I can adjust the size of my game to the browsers fullscreen while maintaining my desired aspect ratio?

 

I'm fairly new to html5 development so any and all feedback is appreciated thanks.

[agamemnus]

In a 3d game with zooming, people use mipmaps (https://en.wikipedia.org/wiki/Mipmap). You can do the same, perhaps.

[hubert]

sure! If youll pass the resolution to the renderer instance the textures will be rendered in smaller resolution and while doing that you can stretch the canvas to fullscreen. This will force pixi to do all the calculations with smaller textures and the browser will render them fullscreen.

 

pass the width and height to autoDetectRenderer and use them as a measurement for all of your assets while adding them to the stage. and than stretch the canvas fullscreen.

 

You can use this as a reference to get the feel http://html5hub.com/screen-size-management-in-mobile-html5-games/

 

http://www.sevenative.com

[agamemnus]

Well, of course that would look pretty blurred (or pixelated, if you want to pixelate it). Not an optimal solution, but a quick fix.

[hubert]

yeah, depends how fast you need to get your product on the market, and in case of pixel arts is not really an issue!

As for aspect ratio things are a little bit trickier since there is the retina apple.

 

I've been over so many performance issues on this forum myself.

 

Some quick questions:

 

1. Are you using sprite property.visible - true/false in your project?

2. Is it possible to render more than one display object container into a new texture element like background texture.

3. Is it possible to adapt culling for some of the parts that are outside of the viewport.

4. Can your stage or area that you are moving around be generated asynchronously with webWorkers not to trash the memory with having everything in ram?

5. Is there any kind of repeatable element that can be put into a spriteBatch.

6. If you have a collision physics are they fixed step or are they made every loop iteration.

7. Have you checked your cpu profile and memory management in chrome dev console. Maybe there are things that you could unload.

8. Another thing. from my experience not all elements in the loop have to be checked every iteration. Some can be dome every second or event tenth iteration without causing any abnormal behaviors of your physics engine. (again fewer cpu cycles).

9. some of the rendering behaviors can be faked with simpler techniques that visuall give you the same effect but are done by a neat tricks.

 

Look: This is a html5 mmorpg with open word and randomly generated terrain. It runs full screen with 60 FPS without a problem. In first version we had a lot of problems since we wanted to have a lot of cool features, like (weather  - rain, show, terrain where tiles randomly overlapped each other to make them look even more real, semi transparent elements that are so big that they are covering the whole player. )

 

First version runned at 38 FPS - this is unacceptable for browsers not to even mention mobile devices. But here it is all this effects running at 60FPS.

 

sorry for the scar but i have a crappy recording software on my computer.

 

LINK TO THE VIDEO:

https://www.youtube.com/watch?v=K8oGU7XEHHU

 

http://www.sevenative.com

[agamemnus]

Camstudio Recorder, perhaps?

[achexi]

Thanks for the response guys, all constructive advice.  In the end It turned out the pc I was testing on had a malfunctioning gfx card (if only i bothered to check the actual memory usage in chrome dev console earlier, I would of realised it would run on anything.) So thankfully it now runs flawlessly on a benchmark 6year old laptop.

 

As for hulbert, I am pretty much doing everything listed in your questions except no collision and no async since theres not a huge benefit due to the small scale of the project. You would think after already having everything you listed that I would of seen red flags to check the hardware but at least I finally found the problem! 

 

I guess something to change would be to revert my game logic right now I was drawing at 60FPS but only calling game logic every 15frames to limit the stress haha. Doesn't really affect how the project runs though since its not really a game its just an art project so I don't need to call it often.

[hubert]

hahahahahahah!  Camstudio Recorder indeed!