BrickGame 3000

Applications, Games, Tools, User libs and useful stuff coded in PureBasic
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

BrickGame 3000

Post by Lunasole »

Glad to say I've finally finished (or rather completed for 80% ^^) one of my game dev attempts.

Here is current version:
http://geocities.ws/lunasole/data/_game ... game3000/l
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
User avatar
Kuron
Addict
Addict
Posts: 1626
Joined: Sat Oct 17, 2009 10:51 pm
Location: Pacific Northwest

Re: BrickGame 3000

Post by Kuron »

I really like the style of graphics you used. :c)
Best wishes to the PB community. Thank you for the memories. ♥️
User avatar
RSBasic
Moderator
Moderator
Posts: 1218
Joined: Thu Dec 31, 2009 11:05 pm
Location: Gernsbach (Germany)
Contact:

Re: BrickGame 3000

Post by RSBasic »

Image
Image
Image
#NULL
Addict
Addict
Posts: 1440
Joined: Thu Aug 30, 2007 11:54 pm
Location: right here

Re: BrickGame 3000

Post by #NULL »

looks very nice, reminds me of something :)

i used wine to test it and the menu bars are empty (no font?) but can be selected via return. in the game the controlls are very laggy, as if events are not processed properly or only periodically. but that might be just a wine thing, can't tell.
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

#NULL wrote: i used wine to test it and the menu bars are empty (no font?) but can be selected via return. in the game the controlls are very laggy, as if events are not processed properly or only periodically. but that might be just a wine thing, can't tell.
Current event handling is actually bad even on Windows (for example, when holding game window with mouse, game loops stops). Should be that also creates perceptible input lag on Wine. Going to fix it sometime, thank

What about font it is like other graphic generated on fly and OS-independed, something else is wrong
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

Added 2-players mode (hotseat) ^^

For now I'm stopping fooling with it, but It's just a beginning with those basic "classic" modes.
I have such a lot ideas for that game, from time to time will add something. Even though there is no much point to continue "seriously", it became interesting itself
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

Lunasole wrote:Going to fix it sometime
Damnit it's not so trivial.
For now all the stuff is done in single thread, and when I trying to separate it from window events handling, I encounter lot of problems.
Like "can't use DisplaySprite in other thread", "cannot create sprite in thread other than where screen opened", "cannot clearscreen() when startdrawing() is performed somewhere".

And that's relatively small game.
Probably I'll fix those problems (and hope those fixes would not be too ugly). But nothing to say in total, it's surely almost impossible to create some more or less complex 2D game in PB (don't know about similar issues with Ogre). Seems that only solution is SDL anyway.
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
#NULL
Addict
Addict
Posts: 1440
Joined: Thu Aug 30, 2007 11:54 pm
Location: right here

Re: BrickGame 3000

Post by #NULL »

you wouldn't necessarily need threading to have the event proccessing correctly i think.
just a guess: do you process all waiting events in one main loop iteration, or only one event per main loop iteration? because the latter would lead to exactly what i experienced with the laggy keys.

Code: Select all

Repeat
	...
	Repeat
		event = WaitWindowEvent(5)
		...
	Until Not event
	...
Until quit
another reason i could think of is when you receive some event and then take some action (like drawing maybe) that generates other events, possibly the same event again.
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

#NULL wrote:just a guess: do you process all waiting events in one main loop iteration, or only one event per main loop iteration? because the latter would lead to exactly what i experienced with the laggy keys.
I've tried both variants without threading, in any of them loop stops on WaitWindowEvent/WindowEvent when you dragging window by mouse (or window menu opened).
Those input lags occuring the same way I think. Maybe it is problem with PB internal events handling, or maybe Wine makes those lags perceptive (unlike lags existing on Windows with events normally) I don't know.
#NULL wrote:another reason i could think of is when you receive some event and then take some action (like drawing maybe) that generates other events, possibly the same event again.
No, it doesn't depend on events. Only close window event is processed at all

As for me anyway threading is needed for performance and if going to extend game.
Or some other way to remove effect of window events processing is needed.
Still the problem is with implementing any of it ^^
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

Hah, seems I'm completely out of ideas to resolve this shit.

Current workaround: do not use windowed mode at all.
That's stupid workaround, but seems to be one which allows threaded graphics (and not only it) run fine in PB.
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
firace
Addict
Addict
Posts: 899
Joined: Wed Nov 09, 2011 8:58 am

Re: BrickGame 3000

Post by firace »

Lunasole wrote:Hah, seems I'm completely out of ideas to resolve this shit.

Current workaround: do not use windowed mode at all.
That's stupid workaround, but seems to be one which allows threaded graphics (and not only it) run fine in PB.
Hi there,

I'm sure there must be a way... As shown in the below 2D game (entirely written in PB), which has impressively smooth scrolling and animation:
https://www.contralogic.com/games/dagion/

Unfortunately, source code doesn't seem to be available.

(That said, I know nothing about game programming.)
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

@firace thanks for interesting PB game example, It looks nicely done. What about scrolling, it's regular (camera fixed).
Also probably it suffers from same problems if run on Wine (if that my guess about connection to lags on moving window using mouse is right).

For now I've dropped attempts to make graphic threaded (as that looks not applicable, at least using OpenGL or DirectX9. I also tried creating my own window using CreateWindowEx() WinAPI but results are same, so no problems with how PB handles messages).
Instead I've tried some other idea, maybe it is even not worst comparing to previous ^^

Here is update:
http://geocities.ws/lunasole/data/_game ... game3000/l
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
#NULL
Addict
Addict
Posts: 1440
Joined: Thu Aug 30, 2007 11:54 pm
Location: right here

Re: BrickGame 3000

Post by #NULL »

It seems to run much better now. the keys are responsive and its is playable. It doesn't freeze here if i drag the window by the titlebar. Gtk or the Window Manager probably just don't behave like that, wine or not. The freezing is a Windows thing (the event-polling thread is blocked) and has nothing to do with purebasic. You could use threading do keep updating the game logic and timing during the window dragging/moving, but even drawing in a separate thread won't help with the visual blocking/freezing, since events are not processed if your event-thread is blocked by windows. i don't know if there is a way to work around that.
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

Updated to newer version. At last optimized some things, now it's MUCH better and should run cool on almost any CPU.
And after this I'll probably stop fooling with those "technical things" and maybe do something with game itself ^^ Because damn that "excessive perfectionism", all goes too slow if play too much with code.

Also already there are some gameplay changes (like better input), all in readme
#NULL wrote:It seems to run much better now. the keys are responsive and its is playable. It doesn't freeze here if i drag the window by the titlebar. Gtk or the Window Manager probably just don't behave like that, wine or not. The freezing is a Windows thing (the event-polling thread is blocked) and has nothing to do with purebasic. You could use threading do keep updating the game logic and timing during the window dragging/moving, but even drawing in a separate thread won't help with the visual blocking/freezing, since events are not processed if your event-thread is blocked by windows. i don't know if there is a way to work around that.
Threading videostuff anyway is not a solution (except maybe using DX11 susbystem, which is bad idea).
For now I've already fixed that lagging with window title, for that threading not needed.

Also thank for saying previously about processing all events before draw, I also added that (again) (not adding it previously was really stupid mistake, cause even in PB help it's mentioned ^^)
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
User avatar
Lunasole
Addict
Addict
Posts: 1091
Joined: Mon Oct 26, 2015 2:55 am
Location: UA
Contact:

Re: BrickGame 3000

Post by Lunasole »

One more update.
Now "technically" main code (game engine, video, etc) is ready for ~90% ^^
Except sounds/music of course, but such things are really simple and may be added anytime.

I don't know yet what will be further, but generally I like this engine, comparing to one from my first attempt (which was "too ambitious" to be done in single-mode). Kind of progress, lol

Also here I've posted this "demo" mostly for feedback/critic, will be glad to get some

Code: Select all

1.0.1.8
  - improved graphics
  - fixed tricky bug with rotation
  - few more important changes (internal)
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
Post Reply