This should be fixed now in the latest build, v0.7.4. Let me know if you still run into any issues?
Pixel Vision 8
Recent community posts
I've discovered some issues cased by compiling the Game Creator with Unity 2017.1 and have reverted to the last stable version of Unity. I should have a new build with exporting restored by the end of the week. Going to see what other small bug fixes I can do as well. If you are having issues with v0.7.3 I'd hold off until Friday's v0.7.4 release.
Is anyone having issues with v0.7.3a on Windows? I've been getting reports of the app not opening or loading to a grey screen. If you see this on Windows or any platform send me an email firstname.lastname@example.org so I can help trouble shoot any issues.
This is an untested build of the Game Creator allowing developers to try out early features going into v0.8.0a. Make sure to back up your workspace before opening/installing it. For this update, you should create an entirely new Workspace folder. Find the default location and remove the old bios and core workspace, then start up v0.7.3 to let it recreate the workspace from scratch.
- Completely new Workspace API. The entire system has been rebuilt in preparation of v0.8.0.
- System Tool and Demos are now not part of the build. This will help reduce file size. You can download them and manually install only what you want/need. Future builds will automate this.
- Creating a new game will now warn you before overwriting an existing one.
- Creating a new game will automatically archive the existing game and move it into the trash. The trash may be set to delete when exiting the game so check your settings.
- File picker action buttons have been rebuilt. They now disabled when no action can be performed and enable based on the context.
- Import and Launch have been removed from the File Picker and will be added back in a future build.
- All built in tools are now located in the Game Creator’s data/StreamingAssets folder which is different based on the OS it’s running on. This allows tools to be built into the Game Creator itself and makes updating them easier in the future. If you use an existing workspace, you can remove the old .pvt files from the archive folder.
- Fixed Copy and Paste help text in Settings screen for workspace path panel.
- Fixed bug in Sprite Builder that would not create a new sb-sprites.lua file from scratch.
- Fixed scale InvalidCastException which happened after changing the scale and reloading the settings tool.
- Fixed issue with DrawSprites and scrolling along the Y position.
- New bios which is built into the GameCreator and manages core settings. The bios file in the Workspace now overrides any default values. This will make adding new properties to the bios easier in future updates.
- All system tools are now defined in the bios including error messages and more. In future builds you will be able to load in custom tools for specific tasks.
- Escape button now stops a running game and load the last tool. Escape will not reload the game, you’ll need to use Ctrl + 1.
- Fixed issue when drawing tiles outside of the tilemap boundaries. Now the tile will wrap to the opposite side.
- New internal URI system for loading game. There are two root locations, System (built in) and Workspace (user defined) allowing more control over how and where games are loaded from.
- New Load APIs exposed to the global runner. You can call LoadGame(), LoadTool() and EditGame() from global and pass in the Game Creator URI path.
- Workspace/Lib folder is now Workspace/Libs folder. The previous framework UI scripts have been moved into the Game Creator’s system folder and each component is now its own Lua file.
- Fixed Sprite Builder button to only show up when a SpriteBuilder folder exists.
- When archiving a game, all files in the Workspace/Game folder are saved including folder structure. Past versions only saved core files. This now allows you to save all external files associated with your game but are not needed by the Game Creator in a single place. Any files that Game Maker can’t use are ignored and do not count against the file size limitation.
- Exporting games to HTML5 is disabled until the new runner can be updated.
- Preloader hangs on large games. This is a known issue and while the preloader was rebuilt in this version, there is still work to be done to optimize this.
I've been trying to get on a two-week release schedule which would make the v0.7.3a updates due today. Unfortunately, the build isn't ready. Figured I'd do a quick post about what I'm working on and highlight the features being added:
- Rebuilding the workspace logic - This has been on my list for some time. While you may not notice the changes, there is a lot of optimization that needs to go into cleaning up the workspace APIs under the hood. The long-term goal is to get the built in demos, tools, and systems out of the user's workspace folder and move them into a dedicated space which is part of the app. This means that the user workspace will only contain your own work, making it easier to switch between workspaces without the need for the engine to copy over all the core files or check for them on boot up.
- Fixing tool and game boot-up times - Right now loading tools is taking too long. I have already increased the boot time for games and tools by 4x but there is still more that can be done. The biggest thing is that I'll be caching tools in memory so when you return to a tool, it will instantly load. The only thing that will always be reloaded from scratch is the contents of the Workspace/Game folder. There are still some issues to work out but the goal is to make working with tools a lot more seamless but still retain the flexibility of each tool still being a PixelVision8 "game".
- New UI in tools - a lot of the UI is still hard coded which is making changes very difficult. I'm working on adding contextual buttons to the bottom of each tool and these will be dynamically generated. For the most part, it should be a transparent change that will greatly improve UX. Clicking on an item may add or remove options and static options that can't be used will be properly disabled or enabled based on the use case. Long-term, this will help you create your own tools a lot easier instead of having to rely on hard coding everything.
- Bug fixes to the sound and music tools - during the last major release, the sound, and music tools ended up with some bugs. The music tool, in particular, has some show stopping issues when you go to the configuration screen. I'll be addressing all of this before the next release.
- DrawSprites method - there is a helper method for drawing sprites to the display which allows you to create graphics bigger than 8x8 pixels. There are some bugs where this method doesn't work when scrolling the screen on the Y axis. I'll be fixing this but possibly moving it over to an external lua file. While this will be transparent for the most part, I want to try and break out helper functions into external code libraries so they are easier to patch and show others how to add functionality to the core APIs.
- Clean up the runners - Right now the export option is still very experimental. While I like the idea of using pre-compiled runners, they added significant size to the installer and I still can't get the Mac wrapper to work correctly. I may rebuild this so that the only pre-compiled export option is WebGL and you can use the open source git project to manually compile your own game for different platforms in Unity. I don't think I'll sort this out fully for v0.7.3a but expect to see the other options disappear and only have WebGL and src remain until I can figure out the best way to approach this.
There is a lot here and my plan is to just roll this out with the next milestone in 2 weeks to stay on schedule. If you run into any bugs in the stable or experimental builds, please file them on the github page here .
Those tools are still under development. I hope to be able to get preview versions of them in next month. The ideal solution for right now is to really use external editors. Still debating if that will be the main workflow moving forward or if I'll be adding in better support for in-app editors.
Thanks, the tools use overscan to hide the mouse. I bet I have some issues with trying to draw the cursor position outside of the texture boundaries I can address in a future release. I appreciate the extra details.
Thanks for the reminder. I added this to the release due at the end of the month. I want to clean up some of the workspace logic and once I do that I'll add in a better way to define the collision flags so they work correctly and you can define your own colors.
This is really great so thanks for sharing. I could actually use this to help with testing out the tilemap logic. I have a few bugs still in there I need to hunt down and was going to try to port over some of my own map generation code to do it.
Thanks, I've seen that before but haven't had a chance to fix it. Think I introduced some issues when I refactored the tilemap code in 0.7.0. I'll add it to the list when I get a chance.
Can you tell me what tool you were in and which side of the screen it happened on?
Sorry about that. I noticed that bug a few days ago but forgot to log it. There is something wrong with scrolling on the Y axis and the DrawSprites method where it tries to hide stuff that it thinks is offscreen.
I'll add it to my list for the next update which is in 2 weeks. I'll update it here if I figure out a solution quicker.
I've logged the bug here .
Can you please file this bug on the github project page so I can track it a little better? Also, are you adjusting for the scroll Y when you redraw the sprites? There may be a bug in DrawSprites(). I noticed that the mouse wasn't rendering correctly on the Music Tool's config screen which is shown by changing the scroll Y position. That logic could do with some more testing.
This is an untested build of the Game Creator allowing developers to test out early features going into v0.8.0a. Make sure to back up your workspace before using and you may need to create a new workspace to get access to the new Save and Settings tools, or just manually delete them from your Workspace’s Archive folder. Here is a list of features:
- New save tool which allows you to preview a game’s files, archive the project and export it.
- New export workflow which supports creating Pixel Vision 8 runners for Windows, Mac, Linux, and WebGL.
- Redesigned Settings Tool with support for fullscreen and scaled window mode.
- New API to get the frames per second value. Call editorBridge.fps and it will return a read-only int for the current frames FPS.
- Various bug fixes to tools.
I know, it's hard to build a game engine on a moving target. The goal is to be in beta by end of the summer so I can start focusing on cleaning up all the issues by the end of the year. I'll see what I can do to fix the background in the next release. The plan is to tackle smaller scope and get releases out every two to three weeks.
I'm working on a better way to do screen split like this. I won't have a fix for a build or two. I really need to rethink how clear and background rendering work because the current implementation isn't going to be good for a game like yours when you need a mouse in a part of the screen where scrolling isn't happening.
This is a good idea. That is sort of what the Game Creator does with the editor. It exposes a whole set of APIs that are not part of the final game. Over time I'll continue to flesh that out more so it will be easier to debug games.
Glad to hear it worked. I'm slowly migrating all of the tools over to use it plus the SpriteBuilder now generates its data into an external lua file you can just import to help keep your main code clean.
Glad you like that feature. That was the intention the entire time. It's why I open sourced the SDK so you could easily move your GC games over into Unity or MonoGame and continue working on your game without limitations.
What sort of limitations are v0.7 imposing that you didn't feel existed before? I didn't add anything new but fixed a bunch of broken stuff that may not have been working correctly in the past. I'm struggling a bit with how much to lock things down. The sound is the biggest topic internally. I really want to open up sound to let people add their own wavs but the file size limitation would go out the door. I'm actually thinking of easing up on a few things but long term the Game Creator is really for people new to fantasy consoles and the export to Unity option, which I'm currently working on, is to take your GC game "sketch" and continue to build upon in an unrestricted way.
Right now the feature is experimental. Not sure I'm happy with how it works currently. To your point, it's not ideal. So the way I had envisioned this in its current implementation is that you don't redraw the display where the HUD is. Since you don't clear it, that pixel data is persistent from frame to frame. So you draw it once, then during the game, you just use sprites as stamps to change a few elements like numbers or icons. It will count against your sprite total which is a side effect. I may just open up drawing tilemap data multiple times in a single frame and you'll just have to work around any performance penalty.
The alternative, and what is closer to real hardware is to split the actual background draw per vertical scanline. I may allow a way of blocking off a range of scanlines. Not sure yet. But feedback like this is really helpful. Trying to find the balance between accuracy and ease of use.
I'm happy to announce that you can check out a demo of the new Pixel Vision 8 WebGL Runner here .
This will be part of the next release of the Game Creator and allows you to export games and publish them online. While this demo is a good first step there are still a lot of things that need to be added in. The template will launch without sound support for now until we are able to rework the sound rendering engine so it can use the correct Audio APIs. But performance on the desktop should be at native speed and loading your own .pv8 game to the template is as easy as changing a single variable. Eventually, the Save Tool will export the template and your game into a single zip you can easily upload to sites like itch.io.
Would love to get your feedback and let me know if the demo runs. I've even tested it out on mobile and while the FPS is a bit low it did run.
That's not good. Let me go back over the mac build and test. Unity has been having some issues with Mac builds lately like not returning the correct version number (which I use for upgrading) and maybe my compiler code to switch controller shortcuts is broken on Mac but works on PC.
So to answer your last question. In order for PV8 to optimize drawing the tilemap, it first draws it into a cache so the raw pixel data is always available. When the renderer samples the tilemap and copies it to the display, it's taking the pixel data from the cache. Any time you change a tile, the cache is updated with the new pixel data from that tile's sprite.
You can draw directly into this tilemap cache with the new drawing APIs when you use DrawMode.TilemapCache. This is useful for things like UI or pixel data you want to sit on top of the tilemap but below the sprites. You can use it as a canvas to ignore the sprite and tilemap rendering pipeline altogether. Just note that it's a bit expensive. The ideal way to use it is to draw pixel data such as text and GIU over tile data then when you need to get rid of it, you can just call Tile() to update the tile itself and the map will redraw the tiles over the pixel data you created with DrawMode.TilemapCache.
Hope that clears things up, it's a bit confusing. I need to document it better.
Good work. I'll see about including this into the core engine so you can just call the variable directly. I also want to have one that tally's the current number of sprites on the screen too. A lot of room to expand on for this feature.
For the next release, I am working on a publishing solution that will allow you to take your games out of the Game Creator and compile them in Unity, MonoGame or use WebGL. Hopefully, this will be a short sprint and the goal is to have it out in the next week or two so people can begin testing it out. I also have a few bugs to fix so I plan on patching v0.7.x until there is enough in there that is stable to officially make it a v0.8.0 release.