[b]Untextured Entities[/b]

I worked a bit on rendering untextured entities. Previously they weren't displayed at all. Unfortunately, it looks like QT cannot (at least as far as I could see) do the OpenGL-style gourad shading that the engine does. Marcel claims that it can… so I'll let him fix that later. ;)

Currently an untextured entity within the scene is filled by the color supplied for its FIRST vertex. In the future the actively selected entity will also be highlighted within the scene. 

[b]Creating/Managing Assets[/b]

The majority of my work with this release has been focused on creating Entities/Levels/Areas. Previously the toolkit could load in everything that was created manually and manage it (fairly well). Now you can create new Projects, Levels, Areas, Entities, attach components, etc.

[b]File Menus[/b]

I completely redid the file menu toolbar, because I thought the previous one was inefficient and didn't organize things as logically as I would have liked them to be. Most of the current menu options have been implemented. The ones that have not have been disabled with a warning saying "I'M WORKING ON IT!" so you'll know which ones aren't. ;) These are generally options that are going to require additional GUI dialog boxes (settings) for Marcel to make. 

[b]File->New->Project[/b]: Creates a new Project

This has actually been disabled. Why? Because you are going to have to supply a project name and some other data before the project is created. Marcel needs to make this GUI. In the meantime, do a Save As… to someplace else to get a new/duplicate project.

[b]File->Open->Project[/b]: Browses for a project directory and opens it for editing.

[b]File->Close->Project[/b]: Closes the current project and removes it from the editor.

[b]File->Save->Current Project[/b]

[b]File->Save->Current Level[/b]

[b]File->Save->Current Area[/b]: Saves the current assets

[b]File->Save As…->Project[/b]: Saves the current project in a different location.

I was actually going to disable this, because you need to be able to specify a name to save it as (not just a directory to save it). It currently works like Export. Creates the same project directory in a new directory that you specify.

[b]File->Import->Level[/b]: Imports Level into Current Project

[b]File->Import->Area[/b]: Imports Area into Current Level

[b]File->Export->Current Level[/b]: Exports Current Level to specified directory

[b]File->Export->Current Area[/b]: Exports Current Area to specified directory

These are useful for moving Levels/Areas around within different projects. If we want to send each other assets in the future, we don't necessarily have to send the entire Project directory.

[b]Project->Settings[/b]: Pops project settings dialog on Current Project

Currently disabled until Marcel makes/fixes said dialog

[b]Project->Add Level[/b]: Creates a new level and adds it to the Current Project

[b]Level->Settings[/b]: Pops level settings dialog on Current Level

Currently disabled for the same reason.

[b]Level->Remove[/b]: Removes the Current Level from the Current Project (and permanently deletes it).

[b]Level->Add Area[/b]: Creates a new area and adds it to the Current Level

[b]Level->Reload Sheets[/b]: Reloads tilesheet.png and objectsheet.png for the Current Level

Fuck! I just realized as I was typing this that I never actually tested that… It should work in theory…

[b]Area->Settings[/b]: Pops area settings dialog on Current Area

Disabled for the same reason as Project and Level Settings.

[b]Area->Remove[/b]: Removes the Current Area from the Current Level (and permanently deletes it).

[b]Area->Add Entity[/b]: Creates a new Entity and adds it to the Current Area

[b]Menu->Terrain[/b]: Currently doesn't have any options, but it will be for terrain (tile/object) manipulation

[b]Menu->Entity->Remove[/b]: Removes the Current Entity from the Current Area (and permanently deletes it).

[b]Menu->Entity->Attach *[/b]: Attaches the specified component to the Current Entity

[b]Menu->Entity->Remove *[/b]: Removes the specified component from the Current Entity

[b]Menu->Engine->Win/OSX/Nix->Invoke[/b]

[b]Menu->Engine->Dreamcast->Invoke[/b]

[b]Menu->Engine->PSP->Invoke[/b]

[b]Menu->Engine->iOS->Invoke[/b]: Saves the Current Area and invokes the engine with it

This is currently only implemented on Windows/Linux/OSX. The other three will require some clever batch/bash scripts that have yet to be written.

I spent a VERY, VERY long time on this stuff. You have no idea how many bugs can occur here. Adding areas to a NULL level, trying to add Areas/Levels of the same name to the project, updating the viewports when something gets added/deleted, updating the file options so that they are only active when valid…

Each option has been carefully disabled when the user can fuck something up. If there is no current Project, the project menu is grayed out. Same with level, area, and entity. Components have some clever logic to ensure that you cannot attach a component that depends on another component that hasn't been attached to the entity. Same with removing components with dependencies on one another. 

[b]Saving Optimizations and Dynamic Sheet Recreation[/b]

Another thing that I worked on was making sure that each level was capable of dynamically regenerating its own sprite sheets based on what is sitting in RAM. This is so that we can create Pritam's "tile manager" to allow you to reorganize the sheet and import sprites from other sheets seamlessly. This functionality isn't in yet, but the build is at least dynamically allocating sheets that have potentially been screwed with.

If the sheet has NOT been screwed with, and the project is saved (or exported elsewhere), a simple file copy is used rather than wasting resources and trying to regenerate the sheet from what is located in RAM:

Debug::Log(Debug::REGULAR, "Dumping tiles.n"); if(!qdir.exists(dir+"/tile")) { 	if(!qdir.mkdir(dir+"/tile")) { 		Debug::Log(Debug::CRITICAL, "! - Could not generate 'tile' directory!n"); 		success = false; 	} } if(_open || (!newLoc && !QFile::exists(dir+"/tile/tilesheet.png"))) { // Dynamically regenerate sheet for open level and new levels 	Debug::Log(Debug::REGULAR, "Generating tile sheet...n"); 	if(!TileManager::GenerateTileSheet(dir+"/tile/tilesheet.png", 512, 512, 32, 32, _tileSheet)) { 		Debug::Log(Debug::CRITICAL, "! - Could not save tilesheet!n"); 		success = false; 	} } else if(!_open && newLoc) { // Copy existing sheet from previous directory to new directory 	Debug::Log(Debug::REGULAR, "Copying tile sheet...n"); 	if(!QFile::copy(_location+"/tile/tilesheet.png", dir+"/tile/tilesheet.png")) { 		Debug::Log(Debug::CRITICAL, "! - Could not copy tilesheet.pngn"); 		success = false; 	} } 

[b]Multiplatform-As-Fuck-edness and Stable Releases[/b]

This release works on Windows/OSX/Linux. Both the engine and toolkit for each platform should be in the root of the Project directory. I have tested them all, and they *should* work (unless I have forgotten some DLLs or some shit that I have and you don't). They should be ready to run.

You can also build the engine and toolkit on any platform from source. Don't you dare bitch about compile errors. I just did it on each. ;) If you do have issues, do a fresh checkout of Engine and Toolkit, because you done fucked something up… Here's your goddamn proof!

There are currently several test levels/areas within the project repository for you to screw with (including test entities). There is nothing really impressive now. The engine also does some random stuff with party members (so don't be surprised if you're hitting random buttons) and other things, because I was using certain keys to debug the last time I was working on the engine. The main functionality is with Level/Area/Entity/Component management, so please do fuck around and invoke the engine with your creations.

[b]Bug Reporting/Issues[/b]

As I have said, there are no doubt many bugs that you are bound to encounter. As I've been developing, I've tried my best to test every case that comes to mind, but as Tyler can tell you, I've definitely missed a few. Testing something for a few minutes that you have been coding for several hours is nowhere near as thorough as spending several hours designing and using the toolkit. We've already found several bugs. The chances are that they are very quick few-line fixes that we just haven't run into. Think of the toolkit as a living, breathing piece of software as we create ES. This is its first real release. If you break it, try to rebreak it, and tell us exactly what you did. :D

[quote="List of shit I'm already thinking about"]

1) Component View size default is way too small (Tried to fix, but it's a pain in the asshole. Marcel can do it.)

2) Remove Area/Level does not yet delete the physical directory, it just removes it from the viewable workspace. If you wish to truly delete them, you have to manually delete the directory

3) Using image filenames with spaces in them will cause problems with entity serialization/deserialization because of the way that the assetio stream is reading the strings. Same with Entity names. Going to need to fix a few of those

4) Screwing with textures in general (and the reload texture button) has been a very tedious task to implement and has been the most bug-prone portion of the entire toolkit. There aren't any more issues that I am currently aware of, but don't be too surprised if you run into some.

5) Debug Log is currently disabled. For some fucking reason it was slowing loading/saving down EXPONENTIALLY. I'm going to have to come up with a more efficient way of populating that widget without much extra overhead.

6) Opening multiple projects containing levels/areas of the same name causes some issues in the directory view. I have been well aware of this problem for quite awhile… it's just going to be a SUPER pain in the asshole and require some serious rethinking to fix. :D

[/quote]

Also, I'm not sure, but it seems like there might be a problem with window responsiveness when the application loses focus. It doesn't really do that so much on a Mac. I'm pretty sure this is because it's trying to reorganize/rerender the scene when the window regains focus. Should be a simple thing to fix.

Keep in mind that 90% of the time I've been running it on a Mac. Tyler has tested it a bit on Windows, and Marcel develops about half the time on Windows. I just barely compiled for Linux the very first time and have done almost no testing. In theory, everything should work identically.

[b]Short-Term Plans (this weekend)[/b]

I had seen Marcel complete some pretty impressive stuff with regards to his tile selection/laying algorithm last weekend. He told me just the other day that he should have the entire system done within a day. That means that this weekend should be nothing but integrating everything Marcel has worked on this entire month with my stable build to make an ultimate toolkit release along with fixing any bugs that you guys or Tyler finds. Don't you fucking let us down, Marcel.

I'm also hoping that Marcel and I can implement a bunch of really kickass new GUI ideas that we have all been thinking about. The toolbar in the toolkit currently serves no purpose. We have redesigned it to be far sexier and far more useful. We also thought of a much sleeker way to handle tile/object selection (rather than the two obtrusive-ass sheets at the bottom of the toolkit) that will provide us with much more functionality. I would love to at least have the front-end implemented by the weekend...

I'm also hoping to let Tyler get very intimate with it this weekend as he creates a demo project full of useful sample Lua scripts that demonstrate useful functionality provided by the engine. No doubt this will bring further improvements to the toolkit as we go. I'm also hoping that Pritam will be able to finally begin assembling some actual demo levels so that we can finally see the graphics that he has no doubt been pouring his heart and soul into in action. Whatever demo areas/test levels we get created in the following couple of weeks is what we will be demonstrating in the next Adventures in Game Development. Keep that in mind. :)

[b]Long-Term Plans[/b]

Before Christmas we had an unstable, barely functional toolkit that could only modify a simple tile layer. Hopefully by the end of this weekend, we will have a fully functional toolkit that can perform a shitload of different tasks on both entities and terrain. The work that I have done this month has been to lay a complete framework/architecture with Marcel for all future progress on the toolkit. Everything from here on should be 1/10th as difficult to implement, since it's using an existing framework.

Dynamic tile/object sheet organization should be easily implemented with Marcel's selection algorithm and the dynamic tile/objectsheet generation stuff that I have worked on. That will no doubt be convenient as hell.

Component functionality should be easy as hell to implement. Each component widget is already inheriting from a component framework and is already sitting in the toolkit with a pointer to the respective entity component that it is managing. Its simply a matter of designing a front-end to manipulate the back-end for each component.

Invoke Engine on other platforms should hopefully be a fairly trivial set of batch/bash scripts the toolkit invokes based on your platform. I would like to have those implemented in the near future, just because it will look totally fucking awesome to click a button and see your level running on a Dreamcast.

[b]My next goals[/b]

Other than reintegrating with Marcel, pointing him in the right direction, and fixing any bugs that people throw at me, my main focus is going to be shifting away from QT and the Toolkit. I've spent lots of time here and am pleased with my progress. 

I am about to get my ass to working on some serious web content. There is no way that we're going to miss the opportunity to launch the site with the next video. I hope to do a really good job laying out the Toolkit/Engine/LibGyro frameworks (with screenshots, code, diagrams, etc) and still want to convert all "not confidential" private development rape posts into respective articles.

I also need to take a few days to make sure that each platform is capable of running ESGamma for the next video. There are some assembly optimizations that are now becoming pretty damn imperative. I also had a class on the MIPS microprocessor last semester, so I'm ready to rape that goddamn PSP…

AND THEN we need to make Chapter 18. I want to start the planning phase this weekend as we're working on web content. They will hopefully go hand-in-hand.

[b]Outro[/b]

So there you have it. I'm exhausted and I have an OpenGL project, an OpenCL presentation, a Lunar Rover presentation, and a Psychology test all tomorrow… all of which I have done nothing for. GONNA BE A LONG NIGHT.

…and the rest of you. GET THE FUCK BACK TO WORK!