Release Thruster 1.3 Released

[PokeParadox]

DaveC Yeah it's possible, needs a bit of hackery about what to rnder to which buffer... but it should be possible.
I'll try to look at it sometime this next week. (Weekends are tricky for me to find time for anything...)

EDIT: PS Downloading Dingux toolchain, again will take a look when I can. Is there a nice layout of the controls and which button key they are mapped to. And the screen is 320x240?

 

[DaveC]

DaveC Yeah it's possible, needs a bit of hackery about what to rnder to which buffer... but it should be possible.
I'll try to look at it sometime this next week. (Weekends are tricky for me to find time for anything...)

Cool thanks. I think that would go a long way to make it look better.

 

[zLouD]

EDIT: PS Downloading Dingux toolchain, again will take a look when I can. Is there a nice layout of the controls and which button key they are mapped to. And the screen is 320x240?

Hey,
here are two readme files related to the A320

OpenDingux kernel (currently 2.6.34)
[OpenDingux] Readme-A320

booboo's and similar kernel (2.6.24)
[old kernel] Readme-A320

OpenDingux will replace the old kernel when it's stable.

Greetings

 

[PokeParadox]

DaveC Yeah it's possible, needs a bit of hackery about what to rnder to which buffer... but it should be possible.
I'll try to look at it sometime this next week. (Weekends are tricky for me to find time for anything...)

Cool thanks. I think that would go a long way to make it look better.

Unfortunately I don't know how possible this is. Looking at the code, a lot of the effects expect things to stay the same size and my idea was to block background rendering early if the dimensions were 640x480 and render them to the scaled buffer before everything gets fed into the scale2x filter...

But I don't seem to be able to do this since the background surface is in a different scope to the final SDL_Flip... This combined with the special effects make this more difficult than I had in my head... I don't know if it's still unrealistic, but it may be a bit too much effort for undetermined results...

PS: Thanks for Dingoo info.

 

[DaveC]

DaveC Yeah it's possible, needs a bit of hackery about what to rnder to which buffer... but it should be possible.
I'll try to look at it sometime this next week. (Weekends are tricky for me to find time for anything...)

Cool thanks. I think that would go a long way to make it look better.

Unfortunately I don't know how possible this is. Looking at the code, a lot of the effects expect things to stay the same size and my idea was to block background rendering early if the dimensions were 640x480 and render them to the scaled buffer before everything gets fed into the scale2x filter...

But I don't seem to be able to do this since the background surface is in a different scope to the final SDL_Flip... This combined with the special effects make this more difficult than I had in my head... I don't know if it's still unrealistic, but it may be a bit too much effort for undetermined results...

Hmm bummer. Maybe you could ask Vilmos as a last resort if he knows any "trick" to do it. Maybe since he wrote it he will know an easy way, or will tell you that it would be too hard.

 

[Vilmos]

The way it works (from memory not from reading the code again) is that there is a background buffer, and a level buffer which holds the blocks. There is some nasty code that manipulates the background and foreground independently and does the scrolling and effects. I think the vector and particle effects go on the block layer.

It can be done, but perhaps you should go the native 640x480 or even just go the native size. The particles would be tiny though, maybe better to go half native resolution. If you went to the proper screen size and then use half that it will still look nice. The vector routines all have scaling options built in. Then adjust the level creation to put more blocks in for the increase in screen size. Oh and fix the font size and menu x/y coordinates.

The hard part is the calculation for the level height and scrolling, it needs a little tweaking of the constants fed into it to look and feel right. Oh and the alpha blending of the bottom bar failed in 640 mode, it must be assuming something there instead of calculating from constants.

 

[DaveC]

The way it works (from memory not from reading the code again) is that there is a background buffer, and a level buffer which holds the blocks. There is some nasty code that manipulates the background and foreground independently and does the scrolling and effects. I think the vector and particle effects go on the block layer.

It sounds like 640 x480 would be pretty hard to do as everything would need redesign. Actually doing 2x for foreground and particles makes them thicker and high res for background would make the game elements stand out anyway. High res particles and ship may actually not stand out enough? It depends on which is easier though and I wouldn't know.