• entries
    383
  • comments
    1075
  • views
    352187

Brixtar Updates

Sign in to follow this  
Trapper Zoid

63 views

I commented in a thread recently that the book selection algorithm in the Control Panel must be trying to send me a not-too-subtle message by regularly selecting "Game Programming for Teens" as its top pick. After posting that, it has now upgraded to offering me "Unreal Tournament Game Programming for Teens".

Maybe after this comment, it will start offering "Go back to school, n00b - for Teens".


Brixtar updates are happening, although at a slower rate than last week. The annoying thing about having a long list of updates is that I don't feel ready to release an upgraded version until they're all done. I'll have an update before the end of the week however (i.e. before the MAGIC contest starts), but it might be close.

Updates done so far include:
  • Mac OS X port is ready. My PowerBook wielding brother has tested the direct port of the Windows version for me and says it works fine, so it's a good sign (especially since his Mac has a different architecture from mine). I could release the alpha version now, but I feel a bit guilty if I don't finish all the updates first.
  • The minimising to an icon and then restoring bug is fixed. I felt stupid for not catching that one, but it seems that that particular graphical glitch didn't occur on my computer; might be a graphics card difference? Anyway, the game now reloads all the graphics resources when you restore it from the minimised state; the same as what happens when you resize the screen. The game also pauses when its minimised as well.
  • Mouse support for the paddle is operational. I still need to test it some more to see if it's properly working in all cases. It does make the game significantly easier. I've also got a new cheat - "air hockey mode" - where the paddle can move anywhere on the screen. It's actually a lot of fun like that, although there's an increased chance something screwy will happen with the collision code. I might someday soon make a modified version to play the game exclusively like that.


A question on mouse control however; currently I don't hide the mouse pointer in windowed mode for the game. This means at present the mouse pointer needs to be hovering over the screen to play the game, which is off putting. I could hide the pointer and give full control to Brixtar, but then you'd be stuck playing the game until you quit. Can anyone suggest a good solution?

I'm thinking of trying a combination of key presses or mouse buttons to "lock" control on Brixtar, or maybe having mouse control release when the game is paused. But if anyone can suggest a better solution I'd be eager to read it.
Sign in to follow this  


3 Comments


Recommended Comments

Quote:
I've also got a new cheat - "air hockey mode" - where the paddle can move anywhere on the screen. It's actually a lot of fun like that, although there's an increased chance something screwy will happen with the collision code. I might someday soon make a modified version to play the game exclusively like that.


That reminds me very much of an old Acorn game called Oddball. It had large, scrolling levels (and some shiny particle effects IIRC), and really added another dimension to breakout. It would be nice to see a similar modern game. :)

Quote:
I'm thinking of trying a combination of key presses or mouse buttons to "lock" control on Brixtar, or maybe having mouse control release when the game is paused. But if anyone can suggest a better solution I'd be eager to read it.


I reckon control being freed by a mouse click would do fine. Can't think of anything better myself. (Unless you want to trap the user's mouse until they get a very rare powerup or something, then have the option of freeing it for a brief period. >.>)

Share this comment


Link to comment
Hey,

Just read your reply regarding depth-buffer stuff. I dunno if you're concerned about over-complicating your engine, but one method that would probably work quite well could be:

1) Draw all totally opaque (also includes objects that use colour-keying or alpha-testing as the 100% transparent pixels shouldn't draw to the depth buffer) objects using depth-buffering. No need to use any particular order.
2) Turn off depth-writing.
3) Draw all transparent objects (ones with partial transparency) in sorted order.

This way, you only have to manually sort the objects with partial-transparency (which in most typical scenes is the minority of sprites) and you get free sorting of the depth-buffered ones.

Like I said though, it'll add some complexity to your engine.

Share this comment


Link to comment
Quote:
Original post by LachlanL
Just read your reply regarding depth-buffer stuff. I dunno if you're concerned about over-complicating your engine, but one method that would probably work quite well could be:

1) Draw all totally opaque (also includes objects that use colour-keying or alpha-testing as the 100% transparent pixels shouldn't draw to the depth buffer) objects using depth-buffering. No need to use any particular order.
2) Turn off depth-writing.
3) Draw all transparent objects (ones with partial transparency) in sorted order.

This way, you only have to manually sort the objects with partial-transparency (which in most typical scenes is the minority of sprites) and you get free sorting of the depth-buffered ones.

Like I said though, it'll add some complexity to your engine.

Thanks for posting this in the new comment; I'd probably have missed in the old one. I wasn't sure you'd spot my reply amongst all the other comments.

It's a good plan, and one I might consider when I get to the graphics improvements. Unfortunately, due to the quirks of my game system I don't think it will be that effective. The trouble is that all my sprites are partially transparent, even the ones that at first glance appear not to.

SVG draws sprites with partially alpha-ed pixels around the edges, which I think give them a really nice look when combined in the game. Unfortunately that means I can't use them with the depth buffer technique, and doubly unfortunately it's the sprites that are going to be the ones changing in depth and be the performance issue.

It could work for the backgrounds though, however the backgrounds are fairly stable in depth so should not be much of an issue. It's probably easier to just stick with both opaque and transparent sprites in the same depth list. I honestly don't expect it to be that much of an issue once I write a semi-sensible sorting routine; it's just the simple prototype one I've got now is totally naive.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now