Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Qube

#31
Announcements / Re: Update
2011-Dec-01
Thanks for doing the visuals MrTAToad.

As requested, here are the two exe's to match. SS10.118 (all ok) SS10.179 (not so).

Good luck Gernot, hope it's a super easy fix :)

*edit* these are just the exe files - the images are from this post

[attachment deleted by admin]
#32
Announcements / Re: Update
2011-Dec-01
Quote from: Kitty Hello on 2011-Dec-01
@Qube again, I think it's the background RGB of the alpha part of the image.
See attached image.

I have no idea why the old version was different here. I read all the code but found no difference :(

All you've done is taken out the alpha'd edging and made it flat. You can see when it rotates that it now looks jaggy.

I made that sprite exactly like that to demo the issue. I can't say it any simpler than "It's all worked with 10.118"

OK, let's put this into simple terms :

With 10.118 AND previous version my example works perfect.. Versions above 10.118 since the Android RGB stuff do not work! - ergo, SOMETHING has changed and broken :S - Many sprites have alpha'd edges and taking these out results in hard edges, not good.

Gernot, you have to understand that the example worked perfectly and 100% as it should in version 10.118 and previous. What ever happened after 10.118 has broken something and it's not just a state change on the smoothshading command  :'(

Quote from: Crivens on 2011-Dec-01
Yeah, try different paint packages.

I use Photoshop and have done for years without issue. Also without issue from GLB 7 to 10.118.
#33
Announcements / Re: Update
2011-Dec-01
Here you go, a working of example of the issue in action (download the two attached files and place them in the same folder as the code).

If you look carefully you will see the outline of the sprite is not right as it rotates (the square part gets lighted edges). When it passes the rotating cube you can see the effect get better and worse. Setting smoothshading to false will correct this but bring in jaggies.

If you run this on 10.118 it will run perfect. Run it on a version greater than 10.118 and it is not.

Code (glbasic) Select

SETSCREEN 1024,768,1
CLEARSCREEN -1

LOADBMP "../background.png"
LOADSPRITE "../testSprite.png", 1
CreateCube(2, 30, RGB(200,200,0))

LOCAL phi% = 0
LOCAL x#, y#, z%, sx#, sy#, sz#
LOCAL sx1#, sx2#, sx3#, sy1#, sy2#, sy3#, sw%, sh%
LOCAL x1%, y1%, x2%, y2%, x3%, y3%, x4%, y4%, xcos#, ysin#

x = 0
y = 768 / 2
sw = 32
sh = 32

WHILE TRUE
X_MAKE3D 1, 2500, 45
X_CAMERA 0,0,120, 0,0,0
X_CULLMODE 1
X_AMBIENT_LT 0, RGB(255,255,255)
X_SPOT_LT 1, RGB(80,80,80), 0, 1, -1, 0, -1, 1, 180

X_MOVEMENT 0, 0, 0
X_ROTATION phi, 0, 1, 1
X_DRAWOBJ 2, 0

INC phi,1

X_MAKE2D
SMOOTHSHADING TRUE
ALPHAMODE -1.0
DRAWSPRITE 1, 50, 50

INC x, .5
IF x > 1023 THEN x = 0

STARTPOLY 1, 2
x1 = x
y1 = y
x2 = x
y2 = (y + sh)
x3 = (x + sw)
y3 = y
x4 = (x + sw)
y4 = (y + sh)

xcos = COS(phi / 4)
ysin = SIN(phi / 4)

x1 = x - xcos * sw - ysin * sh
y1 = y - xcos * sh + ysin * sw

x2 = x - xcos * sw + ysin * sh
y2 = y + xcos * sh + ysin * sw

x3 = x + xcos * sw - ysin * sh
y3 = y - xcos * sh - ysin * sw

x4 = x + xcos * sw + ysin * sh
y4 = y + xcos * sh - ysin * sw

POLYVECTOR x1, y1, 0, 0
POLYVECTOR x2, y2, 0, 0 + 64
POLYVECTOR x3, y3, 0 + 64, 0
POLYVECTOR x4, y4, 0 + 64, 0 + 64
POLYNEWSTRIP
ENDPOLY

SHOWSCREEN
WEND

FUNCTION CreateCube: num, sz, col
X_AUTONORMALS 1
sz = sz / 2

X_OBJSTART num
// Front Face
X_OBJADDVERTEX  sz, -sz,  sz, 1, 0, col
X_OBJADDVERTEX -sz, -sz,  sz, 0, 0, col
X_OBJADDVERTEX  sz,  sz,  sz, 1, 1, col
X_OBJADDVERTEX -sz,  sz,  sz, 0, 1, col
X_OBJNEWGROUP
// Back Face
X_OBJADDVERTEX -sz,  sz, -sz, 1, 1, col
X_OBJADDVERTEX -sz, -sz, -sz, 1, 0, col
X_OBJADDVERTEX  sz,  sz, -sz, 0, 1, col
X_OBJADDVERTEX  sz, -sz, -sz, 0, 0, col
X_OBJNEWGROUP
// Top Face
X_OBJADDVERTEX -sz,  sz,  sz, 0, 0, col
X_OBJADDVERTEX -sz,  sz, -sz, 0, 1, col
X_OBJADDVERTEX  sz,  sz,  sz, 1, 0, col
X_OBJADDVERTEX  sz,  sz, -sz, 1, 1, col
X_OBJNEWGROUP
// Bottom Face
X_OBJADDVERTEX  sz, -sz, -sz, 0, 1, col
X_OBJADDVERTEX -sz, -sz, -sz, 1, 1, col
X_OBJADDVERTEX  sz, -sz,  sz, 0, 0, col
X_OBJADDVERTEX -sz, -sz,  sz, 1, 0, col
X_OBJNEWGROUP
// Right face
X_OBJADDVERTEX  sz,  sz, -sz, 1, 1, col
X_OBJADDVERTEX  sz, -sz, -sz, 1, 0, col
X_OBJADDVERTEX  sz,  sz,  sz, 0, 1, col
X_OBJADDVERTEX  sz, -sz,  sz, 0, 0, col
X_OBJNEWGROUP
// Left Face
X_OBJADDVERTEX -sz, -sz,  sz, 1, 0, col
X_OBJADDVERTEX -sz, -sz, -sz, 0, 0, col
X_OBJADDVERTEX -sz,  sz,  sz, 1, 1, col
X_OBJADDVERTEX -sz,  sz, -sz, 0, 1, col
X_OBJNEWGROUP
X_OBJEND
ENDFUNCTION


[attachment deleted by admin]
#34
Announcements / Re: Update
2011-Nov-30
Quote from: Kitty Hello on 2011-Nov-30
I can't reproduce it. Can you please assist?
I will make SMOOTHSHADING ALSE the default for new updates. Might draw sprites a bit quicker then, too.

It's not just backward, it's also wrong ::) - Currently if set to FALSE it displays "better" when static but terrible for rotating. If TRUE it displays "worse" when static but better when rotating. There's definitely something wrong with it beyond being reversed.

#35
Quote from: Ruidesco on 2011-Nov-30
Any news about that planned PC version? I'm throwing money at my screen but nothing happens. ;)

The PC & MAC versions will be coming towards the end of January. They will be the shiny new 1.1 version (to be released in Dec on the AppStore) but with higher resolution textures.
#36
Quote from: ampos on 2011-Nov-29
how are sales going?

Not too bad but could be a lot better. After 1.1 is released I'll be giving it a good push as it'll be a much better game.
#37
Quote
Hey Qube! I found this today: http://www.indiegamemusic.com/viewartist.php?id=323

Phew!! I thought you meant someone had stolen my music and was trying to sell it. lol :P - Tis quite a funky peace that I could slot in somewhere.

While I'm here I can happily announce that version 1.1 will be released (free update) around the 2nd week of December on the AppStore and will feature amongst many other things campaign mode, missions, new weapons, tweaked & improved graphics, control settings, better combat A.I  :good:

So you'll be able to play Galaxix via campaign mode, which makes it more of an arcade / console type experience with a story to follow, things you must do, progress & rewards, etc. Free play which is what it is now, or even quick mission mode for a 10 minute blast. Good stuff on the way  =D
#38
1.. A simple particle engine to avoid z-order fighting or having to manually sort 100's of particles with funky math would be a great help, thanks  :good: - I think OpenGL has a method for using the depth buffer? - I'm sure you'll sort out a speedy method  :good:

2.. Best not go that far then, just for sphere mapping, lol. Seems a tad overkill for one feature  :noggin:

3.. I've sorted it out myself with multimatrix but I was just thinking of other users and new users who go into the 3D side and suffer with gimbal lock. Using multimatrix is not simply an alternative to X_ROTATION though as it requires other hand coded functions when it comes to gimbal lock free rotations.

Thanks for adding no.1 to your to-do list  =D
#39
Hi, Gernot,

What's the chances of upping the abilities on the 3D side of GLB? - I'd love to have, especially for iOS :

1.. 3D particle engine. Even a very simple one would help as right now it's a nightmare to do anything like this due to z-order issues. GLB definitely needs a method for particle effects.

2.. Sphere mapping. I know this is already in but last time I checked it didn't work on iOS.

3.. Added commands for object rotation to avoid gimbal lock. True there are routines already out there but none are 100% bug free. So we could do with built in commands.

Any chance these will make it into GLB? - I'd happily pay to have them in  :good:
#40
Quote
You already can. Set the resolution to 9998x9999 or 9999x9998 (depending on orientation) and it will use the default resolution of your device. Use scaling code and all is good.

I know =D but I, like you, want to be able to in certain circumstances (universal binary) set the resolution for all iPhones to 480x320 even when it's a the HD display but still allow for iPad's. Currently I can do a universal binary but as you mentioned it will default down to the max resolution of the device. This is all well and good some of the time but not all of the time, for example 3D flows much smoother in the iPhones at 480x320 resolution (excluding the 4S as I don't have one to test).

I also would like to be able to (on iPhone 4+) allow the option for the user to run in HD mode. This way they can choose between super sharp graphics vs super smooth game play.

Quote
I could also been some upset if I brought a HD, that run slow (under 30fps) and need to get a SD version for more mone.

Well really it's Apples fault for releasing the iPhone 4 which at 960x480 can't match the performance of a 3GS running at 480x320. The fill rate wasn't substantially improved until the iPad 2 and I assume the 4S applies to that too. It's a bit crazy when you can develop a 3D games for the 3GS and it runs slower on the iPhone 4 due it's HD resolution and underpowered GPU.

The iPhone / iPod Touch 4 running at it's native resolution *should* really be able to outperform earlier iDevices running at their native resolution but they dont unfortunately, eg iPhone 4 vs 3GS.
#41
+1 for being able to set the iDevice resolution so we're able to do universal binaries to support 480x320, 940x640, 1024x768 and sudder the thought but the iPad 3's 2048x1536.

Talking of 2048x1536 which is now the iPad's 3 display (confirmed as far as screen production goes). Are we seriously expected to believe that the iPad 3's GPU will be able to handle full on 60fps games at 2048x1536? - My thinking is that games will really still need to be at 1024x768 and the 2048x1536 will only really be used for non gaming apps.

But I digress... +1 for being able to change resolution to allow for universal iDevice binaries  :good:
#42
Announcements / Re: Update
2011-Nov-23
Quote from: Ruidesco on 2011-Nov-23
SMOOTHSHADING is indeed reset to TRUE after every SHOWSCREEN or X_MAKE2D in your code.

There's more going on than just a state change :S - If I use SMOOTHSHADING TRUE it will display a little fuzzy but rotate properly without jaggies.  If I set to SMOOTHSHADING FALSE then it'll display fine but then the rotation shows jaggies.

I used to set SMOOTHSHADING TRUE at the top of my code and POLYVECTOR would display and rotate perfect. After 10.118 that changed. It's like half of SMOOTHSHADING (static / rotated) works for the opposite state.

I'm sure Gernot will fix for a future update :)
#43
Announcements / Re: Update
2011-Nov-22
Quote from: MrTAToad on 2011-Nov-22
Did you try SMOOTHSHADING FALSE too ?

No, because it was originally with 10.118 & SMOOTHSHADING TRUE and it worked :nana:

*EDIT*

I added SMOOTHSHADING FALSE after each X_MAKE2D command and it works as it should do if using SMOOTHSHADING TRUE at the beginning of your App :good:

I guess this mean that SMOOTHSHADING FALSE is currently working in reverse? + after each SHOWSCREEN this is being reset?

*EDIT 2*

The above works fine for static images but rotation is not aliased.
#44
Announcements / Re: Update
2011-Nov-22
Quote from: Kitty Hello on 2011-Nov-22
Yes. I had no time to check that, yet. But, can you try if it's just a matter of SMOOTHSHADING FALSE after each SHOWSCREEN?

Unfortunately not :'( - I tried adding SMOOTHSHADING TRUE after each SHOWSCREEN plus after every X_MAKE2D and it made no difference.

It's not a big problem as I can continue to use 10.118 as that was the last version that worked perfect :) - I will start complaining when I come to putting my game onto Android  =D
#45
Announcements / Re: Update
2011-Nov-21
10.179 still draws wrong with polyvector (fuzzy stuff as detailed earlier)  :rant: