Context3D "Texture too big" error

[DigiEggz]

When attempting to create a FlxSprite by passing in a png with a size of 1050x140, I get the an error saying the texture is too large. That said, I can't get anything to draw on the screen except for some .swf vectors. All of the other textures are black as well. Here's the debugger log:

ArgumentError: Error #3683: Texture too big (max is 2048x2048).
at flash.display3D::Context3D/createTexture()
at com.genome2d.textures::GContextTexture/invalidateNativeTexture()
at com.genome2d.textures::GTexture/invalidateNativeTexture()
at com.genome2d.textures::GTexture()
at com.genome2d.textures.factories::GTextureFactory$/createFromBitmapData()
at flixel.system.render::FlxTexture/uploadBitmapDataToGPU()[/Users/PRIZZA/Documents/Adobe Flash Builder 4.7/Library/flixel2.57/flixel/system/render/FlxTexture.as:44]
at flixel.system.render::FlxTexture/setBitmapData()[/Users/PRIZZA/Documents/Adobe Flash Builder 4.7/Library/flixel2.57/flixel/system/render/FlxTexture.as:163]
at flixel::FlxSprite/resetHelpers()[/Users/PRIZZA/Documents/Adobe Flash Builder 4.7/Library/flixel2.57/flixel/FlxSprite.as:474]
at flixel::FlxSprite/loadGraphic()[/Users/PRIZZA/Documents/Adobe Flash Builder 4.7/Library/flixel2.57/flixel/FlxSprite.as:334]
at Player/makePlayer()[/Users/PRIZZA/Documents/Adobe Flash Builder 4.7/aeonRivals_dev/src/Player.as:1123]
at PlayState/loginGuest()[/Users/PRIZZA/Documents/Adobe Flash Builder 4.7/aeonRivals_dev/src/PlayState.as:2147]
at flixel.ui::FlxButton/handleMouseUp()[/Users/PRIZZA/Documents/Adobe Flash Builder 4.7/Library/flixel2.57/flixel/ui/FlxButton.as:356]

[DigiEggz]

I'd like to add that I tried implementing the @Dovyski GPU code from the ground up; I followed each and every change he made from the very beginning of the GPU implementation starting with change 347bfa0 (https://github.com/FlixelCommunity/flixel/pull/219]), and even at the earliest stage it black screens me. I also made sure to use an older version of the genome2D to match the same time era of the one most likely used in this build. I feel like it might just need some basic type of change to get it working again with the current AIR/Flash.

I've learned a great deal of how Flixel draws to the screen thanks to @Dovyski 's work and I'm more than willing to help anyone who would like to try to get this working again. I'm enjoying the challenge of optimizing this as3 version and I think fixing this issue would really benefit a lot of the lurkers.

[Dovyski]

While doing tests back then during the GPU implementation, I remember some developers reported such black screen. I was never quite able to pinpoint the reason for that. It might even be a graphics card (driver) issue maybe?

I agree with you that this issue would really benefit a lot of developers and I want to get back to it eventually. I have been so busy lately though. Additionally Adobe made a handful of bad decisions that scared and destimulated lots of developers (me included).

[DigiEggz]

Which decisions are you referring to in particular? I'm sorry that you feel that way, though. At this point, I'm just trying to get Genome2d to work at all, on any front. As you stated before, perhaps we could attempt to port Axel's Stage3D code since it's so similar and it's still being actively updated by Adobe. I was working on it a bit, but Axel made some odd changes by breaking up the "sprite" class into different pieces.

I hope you find more time in the near future, but no worries until that time. I'm grateful that you even made an attempt in the first place and I'll keep trying to put work toward the branch.

[Dovyski]

Which decisions are you referring to in particular?

The Flash/AIR team is doing their best right now, attending online conferences, releasing things and so on. I really appreciate that. From my point of view, though, Adobe seems to be neglecting the spread of their technology, which, in my opinion, means they are not that willing to invest money/time on it.

As you stated before, perhaps we could attempt to port Axel's Stage3D code since it's so similar and it's still being actively updated by Adobe. I was working on it a bit, but Axel made some odd changes by breaking up the "sprite" class into different pieces.

I had the same problems you described. The architecture is quite different and I assume that's because the author had to accommodate all Stage3D things. I still believe Genome2D is a good way to go now (since everything is almost in place for that).

The ideal solution, however, would be to port Axel's Stage3D code to remove any external dependencies (such as Genome2D). A lot of work is required to achieve that though 😃

[DigiEggz]

I'll use a bare bones project and then try to implement it in my most complex project to make sure everything is working correctly. Thanks again for your helpful responses!

[DigiEggz]

Great news! I was determined to get your "mode" dev demo working and I was finally successful! The whole issue when compiling to AIR is the need to pay attention to the layering, type, and transparency values of the UI elements so that the 3d stage is actually visible. Using the latest "dev" build of flixel and SWC of Genome2D, I am able to get a working build on OSX.

I had a few questions I thought you might be able to help with:

1. There seems to be a sort of aliasing on the edges of sprites when in GPU mode. Is there a way to keep the hard edges and sharpness of the original sprites? Here's a comparison between GPU and CPU mode: http://imgur.com/a/Y7DF8
2. Setting the fullscreen via FlxG.stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE; and FlxG.stage.scaleMode = StageScaleMode.SHOW_ALL; in CPU mode will stretch everything to fit the screen, but GPU mode obviously needs to have the viewPort size changed. Do you have an idea on what I might need to update to get the game to draw everything stretched to fit the screen? I've spent a few hours trying to get it to work, but I don't understand the system enough I guess.

I'll be implementing your changes to my current game pull-by-pull, so I can carefully watch what you change with each iteration and learn along the way. Thanks again for your incredible work.

[Dovyski]

That is AWESOME! 😄 🎉 Congrats on such a cool achievement! You nailed this AIR bug that I was hunting over and over during development.

There seems to be a sort of aliasing on the edges of sprites when in GPU mode. Is there a way to keep the hard edges and sharpness of the original sprites?

I don't know. I've made a few tests with Genome2D trying to set the aliasing sample size, but I had no success. I assume there must be a way of saying to Genome2D/Stage3D to not use anti-aliasing. I suggest you to investigate if there is an API call for that, similar to the smoothing property available in the Bitmap class. Maybe you could ask @pshtif about that as well.

Setting the fullscreen via FlxG.stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE; and FlxG.stage.scaleMode = StageScaleMode.SHOW_ALL; in CPU mode will stretch everything to fit the screen, but GPU mode obviously needs to have the viewPort size changed. Do you have an idea on what I might need to update to get the game to draw everything stretched to fit the screen? I've spent a few hours trying to get it to work, but I don't understand the system enough I guess.

From the top of my head, the way I would do it is to adjust the zoom/scale factor used to render sprites (check this line in the renderer). When in GPU mode, Flixel will scale sprites in order to meet the camera zoom, so you could multiply that by some other factor.

Take a look at the pseudo-code below:

var widthFactor :Number = screenWith / viewPortWidth;
var zoom :Number = camera.zoom * widthFactor;

context.draw(_textureFX, renderPosX, renderPosY, zoom, zoom, ....)

I think it would scale up (and maybe down as well) sprites according to the proportions of the viewPort and the screen size. I think this idea needs further investigation and love to work, but that's a start.