H.A.A.R.P Thread [So I don't clog up the gallery and such]

[Road Kill Kenny]

Hi All,

 

I don't like posting images of H.A.A.R.P in the Leadwerks gallery thing because I don't want it to clog up the image thing on the Portal with pictures of H.A.A.R.P. Admittedly it isn't that visually stimulating and I'd rather let the people doing sunsets and cool graphic things to have their images there.

 

Therefore, I've decided I'll just make a thread for H.A.A.R.P and post images here.

 

Today for the first time I used H.A.A.R.P to assist in creating UI elements for the UI editor itself. As you can see below I have made a few elements and put them in the correct positions and such. All I have to do to make it part of the H.A.A.R.P editor and not part of the game is change one cell in the element record to say "HAARP" and a line or so of code in the program.

 

It's good for getting precision positions of the elements visually and it makes even making the UI editor much faster.

 

 

Also you may have noticed I'm making a parameters tab in the left side panel (which is actually a window element in disguise) Although the buttons around the element selection box is good there is no way I can get enough buttons and such to fully edit everything about the UI elements. Therefore, I made this properties panel which can edit other edits such as listed below. It is also good because You can get exact measurements for positions and dimensions which update in real-time when you move them in the screen. You can also type in positions and dimensions into those number boxes as you would expect and it will update the element.

• show label
  
• element type
  
• label text
  
• label offset
  
• label font
  
• label color
  
• Other Element specific things
  

All elements (for first build) are complete and soon they will be fully editable with this property panel. Following, I just have to finish HAARP switchboard and a few little odd's and ends and it will be on to the good stuff.

 

I know that everyone says you shouldn't start with a UI and you should do gameplay. However, this has sort of been an experiment in itself so I wasn't confident to use the 'DDD' and the "make as you play" concept on gameplay straight of the bat. I was more comfortable doing it with a user interface system but now I feel I am confident enough to do it for 3D and gameplay as well. I can't wait to dive into it.Luckily my entire system is based on Finite State Machines so I can work on that in complete isolation to this as if it were another little program.

[Roland]

This is so great and don't bother about what everyone says you should start with.

Do what you are interested in doing and have fun

 

Great work

[Rick]

I'm not sure if you'll have many real-time (constantly in the game loop) read/write situations but if you do and you haven't checked out already, SQLite can run in-memory (the entire DB gets stored in memory) which will give you way more performance than the default read/write to disk. I just point it out because at work we're starting to play more with in-memory DB's for performance gains because we work with so much data. I know you won't have a lot of data but if you want to read/write anywhere inside the main loop it should be much faster if the DB is in-memory.

 

You can attach DB's on disk to in-memory and save it back out if needed.

 

http://www.sqlite.org/inmemorydb.html

[Road Kill Kenny]

I'm not sure if you'll have many real-time (constantly in the game loop) read/write situations but if you do and you haven't checked out already, SQLite can run in-memory (the entire DB gets stored in memory) which will give you way more performance than the default read/write to disk. I just point it out because at work we're starting to play more with in-memory DB's for performance gains because we work with so much data. I know you won't have a lot of data but if you want to read/write anywhere inside the main loop it should be much faster if the DB is in-memory.

 

You can attach DB's on disk to in-memory and save it back out if needed.

 

Yeh that sounds kinda cool. However, I actually query all the data I need and store it in memory myself anyway at launch and in loading screens. So databases are only ever queried in loading screens while in game or if you are using the editor. Once the data has been passed onto the elements I can free up that virtual database.

 

I'll keep it in mind for future tho. Sounds like it could work nicely.

[Road Kill Kenny]

New video on HAARP. Getting pretty close to finishing the first build of the GUI editor part. Then I'll move onto the level loading & gameplay stuff which will be very exciting.

 

 

http://www.leadwerks.com/werkspace/page/videos/_/wip-haarp-gui-editor-almost-finished-r147

[Roland]

As interesting and nice as usual. Great progress there since last time.