I redone the sky in my 2D game for a smoother gradient and I also better optimized it. However, I'm getting this strange black area on the far right:





The texture is 1x256. I set the panel's scale_x value to 1024 to stretch it all the way across the screen (the scale_y value is not used). Oddly enough, slightly less (by 10 pixels) than half the screen has the black area. I tried widening it to 2x256 and using scale_x at 512 and this causes the rightmost 1/4 of the screen to have that black area. The screenshots show the 2x256 version. My previous sky used a 16x256 texture scaled to 64 and it didn't have this problem at all. Why is it doing this and how can I fix it without using a 16x256 texture or using 6.40.4 (as 6.40.4 doesn't have this)?

I'm using 6.31 Commercial (my 2D game doesn't work right (short of adding another 2000+ lines of code) on 6.4x).

Edit: added note about this and 6.40.4

I've also the same problem before some weeks ago. I don't know how to solve it. But I know why the problem appears,here:

video_mode=8; // 1024*768
bmap Example_B=<Example.tga>,0,0,4,16;//init
panel Example_P
{
bmap = Example_B;
layer=1;
}

// in a function
Example_P.scale_y = 16; // possible, because: 16/16=1;
Example_P.scale_y = 32; // not possible, because: 32/16=2;

! Above the value one it isn't possible.

in your game:
Picture=1*256; Scale_X=1024;
1024/1=1024; // not possible(1024pixel not shown)

Picture=2*256; Scale_X=512;
512/2=256; // not possible(256pixel not shown)

Picture=16*256; Scale_X=64;
64/16=4; // not possible(4pixel not shown)

Maybe this is wrong, don't know. I found no solution.

Regards,
beegee

--------------------------
GenuineMotors.de

I tried 1x256, 2x256, 4x256, 8x256, and 16x256. The 4x256 has the last 200 or so pixels on the right cut off. The 8x256 appears correct. I tried viewing it in the 6.40.4 public beta release to see if this was a new bug I found, and this wasn't present in 6.40.4 so I posted it here instead of the bug hunt forum.

The 1x256 version with scale_x at 1024 had the last 523 pixels on the right as black. For the fun of it, I tried scale_x at 512 instead and the same thing occurred - the rightmost half (slightly less than half) was cut off. The 2x256 version with scale_x at 512 (shown in the screenshots above), had the last 300 pixels on right cut off. The 4x256 version with scale_x at 256 had the last 200 pixels on the right cut off. The 8x256 with scale_x at 128 had nothing cut off so I'm currently using the 8x256 version. I'd like to use the 1x256 version (as all pixels on each row are the same color), but don't know how. The only solutions are, that I know of:

1. Just stick with the 8x256 size.
2. Stretch the 1x256 to 2048 instead of 1024 (this may cause the engine to render those invisible pixels that are off the view giving a loss of performance)
3. Use the 6.40.4 release (two things - panels don't appear right as they are cut off (from changing the bmap), and I don't know if I can publish and sell with a public beta release).
4. Find some other method.

Having connection problems....

OK, I think the best solution is, using the final of 6.40. Great to hear that, that this bug is fixed.

Regards,
beegee

------------------------
GenuineMotors.de

I don't think using the final release of 6.4x is what I want. Adding another 2000 lines of code just because of a new feature in 6.4 (panel.size_x) will not only take a long time, but I'd have to retest a lot of things having:

panel.size_x = new_bmap_x_size;
panel.size_y = new_bmap_y_size;

after the several hundred instances of the bmap being changed. That's why I'm using 6.31 instead for my 2D game as I seriously do not like this feature. There's nothing new in 6.4 of any use for my 2D game (no Lite-C, the main thing I need for it) so it's not worth doing all that just to fix this. If I could disable the need to use panel.size_x in 6.4, then I'd use it. It's a feature worse than even MED's bugs.

panel.size_x/y is a great new feature and in most cases would be easier to use than scale_x/y, so i'm sure what i'm seeing is just a misunderstanding and when you describe this feature you just mean it in the context of your game.

i seriously doubt that the use of panel.size_x is compulsory. it isn't a replacement for scale_x, it's just an added feature. do some backing up and give it a go. it might fix your framerate problems and make future development easier, especially since the final release of LiteC is probably going to be more like 6.4 than 6.31, don't you think? as long as you are using current syntax it should work exactly the same. you'll only find problems if you are using already-abandoned code that hadn't been taken out of use yet.

sincerely hope this helps, as i am eager to play the final version of your game.

julz
Edit: sorry, i didn't see before that you already gave it a go. what do you mean by the panels not appearing right "as they are cut off"?

By cut off, compare the same screenshot (from the same position and with the same actions) from 6.31.4 (top) with 6.40.4 (bottom). I have not made any changes to the code in either case. I just opened the script file and clicked on the test run button.





As you can tell, in the 6.4 version, the right 3/4 of the image from the flare effect is cut off. The player isn't because he uses a panel for each image used, of which is very confusing, prone to bugs, and not optimized. When I do optimize it, only one panel will be needed instead of about 30. The flare effect uses 3 panels, each using the same bmap, but with a different alpha for transparency (which, strangely enough, 37.5 for the alpha is actually 75% transparent).

wow, that's really odd?
have you brought this up with conitec? maybe they'll fix it by the next version.

julz

Read the compatibility issues for 6.4:

Quote:

---

When changing a panel.bmap parameter, set panel.size_x and panel.size_y to the size of the new bmap.

---

In 6.31, the panel's size is set automatically. In 6.4, it isn't any more. In 6.4, textures have to be a power of 2. In 6.31, they are broken up. There's no way to assign multiple bmaps to a single panel and move them by moving the panel. For a 2048x96 image, I need 8 bmaps, four 512x64's and four 512x32's. That's why I'm forced to use 6.31 for my 2D game. 6.4 has nothing but disadvantages for it.