Bloxed - A tetris game

[jgroenendaal]

Why don't you make it dynamically scalable to any window size (including fullscreen), as I did in Joop and Vapiki? I assumed you would probably use one or other of those conversions as a 'template' for any new work, to avoid 'reinventing the wheel'.

I have partly avoided reinventing the wheel, as it's based on the Bloxed version I started 10 years ago for BB4W, borrowing some templates from the conversions Joop and Vapiki you did, so converting was done quite smoothly. This included the same resolution output as I did with Soap, meaning different sets to have output for three different resolutions.

I have plans to change that during the development, I discovered SDL can convert SVG graphics as an 'bimap' texture and as the source graphics ( expect the background photos ) are vector based I think this could be a way to get the output more flexible - not sure if this is the best way. SVG is very limited for gaming purposes, so it will probably gets a more uncommonly used reinvention so maybe I should avoid spending time on that.

[Richard Russell]

I have partly avoided reinventing the wheel, as it's based on the Bloxed version I started 10 years ago for BB4W

The big difference between BB4W and BBCSDL, as far as screen/window resolution is concerned, is that BBCSDL has built-in scaling. In BB4W, if you wanted to support multiple resolutions, or optional full-screen operation, you really had only two choices:

1. Write your program in such a way that the width and height are in variables, and adjust everything (sizes, positions) to suit: a lot of work which very few programs bothered with.
2. Leverage DirectX or Direct3D (e.g. via David Williams's libraries or the supplied 3D libraries) to perform scaling for you. Difficult to understand and to make work, and totally Windows-specific.

Things are quite different in BBCSDL. Because scaling is built-in, you can write your programs on the assumption that the resolution is fixed (e.g. 640 x 512 or 800 x 600) and then scale the output to fit whatever size the actual window happens to be, or indeed full-screen. You can't change the aspect-ratio, so if you are outputting to a widescreen display you will get black bars at the sides, but otherwise it's all done for you.

Instructions for enabling the automatic scaling are in the main Help Documentation.

[jgroenendaal]

Richard,

Thank you for your input. Currently I am struggling with some design issues like the resolution. I didn't want to redo the graphics. But I see some issues, so I think I have to consider that I will need todo some principles I have made 10 years ago.

Some thign I didn't like is the fact that the cropped font bitmaps that are downsized afterwards have shifting and the horizon ( probably also vertical but that is less cosmetic ). I am thnking of changing that.

For the moment I added the ability of both joystick and touch controls.
The menu system can be controlled by keyboard arrows, mouse, joystick ( X and Y axis ) and touch screens and I am quite happy with the playability with the touch screen.

In Full screen I need to recalculate the mouse position, but that's only concerning the menu system.

With some tricks in settings I could get it working in some proper way on my Android 15 Phone.
My phone is fast enough to play it properly with both touch and joystick.
My Celeron Chromebook could run it in the lowest resolution - the main menu is very slow mainly because the background is in 2K resolution and not cropped down like in the in-game backgrounds.

https://wasm.bbcbasic.net/bbcsdl.html?a ... bloxed.bbb




Another thing, is that I wanted to prepare some background cycling.
My current methods, is probably not the fastest

Currently what I do is ( based on the Pageturn example ) :

1. Load the high resolution JPEG direcrlt to the screen to the final resolution and offset via *DISPLAY

2. Save this using GSAVE in the @tmp folder as tmp1.bmp

3. draw the player(s) area in PURPLE

4. Save this using GSAVE in the @thmo folder as tmp2.bmp

5. Load tmp1 and tmp2 as Textures

6. Draw tmp1 via GfxPlotScale

7. Do a GfcGaussianBlur3x3

8. Draw the tmp2 as a Texture with the PURPLE as a MASK colour
(this results into a blurry only background within the MASK area)

9. Draw the lines of the player(s) area

10. Save this using GSave

11. Destroy the loaded Textures.

Now, if I want to cycle this with 10 images, it takes a few minutes (escpeially via the online version) to progress this before the game starts.

After being processed, I can loads chunks of the bmp file in to the memory of one if the 10 pictures and swap the background once it is completed - I am not worried this will cause performance issues )

But I think, the processing of this images by saving three times can be done more efficient
I have to dig further to find a proper solution.


Cheers!
Jeroen

[Richard Russell]

But I think, the processing of this images by saving three times can be done more efficient
I have to dig further to find a proper solution.

I'm not too sure what you are wanting to do, but have you investigated the imglib.bbc and gfxlib.bbc libraries, both of which can efficiently and quickly display images? *DISPLAY and *MDISPLAY etc. are not ideal when a high performance is required.

[jgroenendaal]

Richard,

I checked the GFXLib routines and this example : https://www.bbcbasic.net/wiki/doku.php? ... ap_texture
But that last one, didn't let me draw texture on this bitmap texture - at least not as easy as the regular BASIC output as in the example.

I didn't check the IMGLib.bbc myself - I am sorry.
I didn't have much time during this weekend, so I will check that during next week.

I hope this image will explain the current process :

This image shows how I currently achieve what I wanted.
From top to down, the images shows the following steps :

1.load the image
2. Place the image on the screen with cropped in a way it's always full screen but in ratio. ( in my way save it to a BMP file )
3a. Blur the image ( and save it to another BMP file )
3b. Place the image like step 2 - then, use the BASIC RECTANGLE FILL to draw the player(s) field as PURPLE as save it to a BMP file )
4. Load back the blurred BMP and place the 2nd generated BMP with the PURPLE as mask. ( technically I could already skip the first bitmap saving as an optimalisation of my current method - it will reduce one BMP file save/load )
5. Add some final effects to add a glass effect and some borders on the player areas. ( using the AAGFXLib )

[Richard Russell]

I checked the GFXLib routines and this example : https://www.bbcbasic.net/wiki/doku.php? ... ap_texture

That Wiki article (which I had completely forgotten about) was written before gfxlib.bbc was created, I recommend that you don't use the method described there but use gfxlib instead.

1.load the image
2. Place the image on the screen with cropped in a way it's always full screen but in ratio. ( in my way save it to a BMP file )
3a. Blur the image ( and save it to another BMP file )
3b. Place the image like step 2 - then, use the BASIC RECTANGLE FILL to draw the player(s) field as PURPLE as save it to a BMP file )
4. Load back the blurred BMP and place the 2nd generated BMP with the PURPLE as mask. ( technically I could already skip the first bitmap saving as an optimalisation of my current method - it will reduce one BMP file save/load )
5. Add some final effects to add a glass effect and some borders on the player areas. ( using the AAGFXLib )

If that works and is fast enough fine, but because it involves multiple transfers between the CPU memory and the GPU memory (plus saving and loading large BMP files) it is likely to be very slow.

If you want it to be faster, then use the tools available in gfxlib.bbc which does almost everything on the GPU so is super fast. I expect all the steps are already supported by that library, but if it's not obvious how to carry out any of them let me know.

[Richard Russell]

As a proof of principle, here's an image I made entirely with gfxlib. I've cheated, because the 'notches' are blurred when they shouldn't be; to do it entirely correctly (not blurring the notches) would be a little more work.

dice.jpg

[Richard Russell]

And here it is done properly ('notches' not blurred). You can't see any difference with this particular background, but you might with a different background. Again all done with gfxlib and therefore quite fast:

dice.jpg

[Richard Russell]

To illustrate how fast it is, here's an animated version:

https://youtube.com/shorts/Gnz5mQO2mPs

[Richard Russell]

Or run it in your own browser here.