🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Pixel Vision 8

A member registered 1 year ago · View creator page →


Recent community posts

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.

Glad to hear. I have been finding a few other bugs I'll be addressing in the v0.7.2a release next week so if you see anything out of the ordinary let me know.

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.

Are you using a US keyboard layout by any chance? I was testing out the Mac build and I can't reproduce this but a few people have reported issues when not using US keyboards.

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.

I added a property to the EditorBridge that now lets you get the current FPS. I'll look into how to expose memory or if it matters in the current state of the engine.

You can see this in action here .

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.

Yes, it's disabled for now. It's on the list to add in full controller support in a future build.

Ok, I'll go through and flesh out the Font documentation next time I have a chance.

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. 

What version of OS X are you using? I can't reproduce this issue but you are not the first person to bring it up.

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.

BTW, the new API is LoadScript(). Let me know how it is working out for you?

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.

1 - If you use DrawMode.Tile you will need to pass column and row values instead of screen x,y positions like DrawMode.Sprite and DrawMode.TileCache.

2 - Technically they can be called anywhere you want. There is a bug I'm trying to track down with ScrollPosition getting called a bit early on the first frame when putting into Update. Since all drawing happens at the end of the Game's draw call, you just want to do it before you attempt to draw the background, since the current scroll position is stored with that call. RebuildTilemap should be called before your own draw calls that would render into the TilemapCache. You should only use RebuildTilemap though in between game scenes. It's an expensive call and I can clear that up a bit more in the documentation.

Thanks for the feedback, hope the above clears things up and I plan on continuing to add details to the documentation for each version until they are very detailed and clear.

Ok, I can look into this. Are you using version 0.7.0a?

In case anyone else is following the thread, I looked at the code you sent me and cleaned it up. The big thing you want to do is change the frame delay every time you reset the timer.

idleTime = idleTime + timeDelta
if(idleTime > idleDelay) then
    idleFrame = idleFrame + 1
    if(idleFrame > #idleFrames) then
         idleFrame = 1
    end     idleDelay = idleFrames[idleFrame].time
    idleTime = 0

Also, for the index errors, I double checked the drawing API and the issue looks like how you are formatting the tables. One thing that is not happening though are the error messages showing the correct line. I'll look into ways to make that clearer so you can debug it a bit easier.

I wasn't able to really expose this. I plan on testing out a few of the tilemap features for the next build. Hopefully, I can wire this up.

This is on the list but there is a lot of other things that are more important right now. I'd like to get this into the debug menu at some point and offer up an overlay so you can debug while running a game. Need to really think through how to do all of that.

Unfortunately, I don't think this is something I can do. If I expose the Lua API to run command line exes it would expose the entire system to hacking. I actually do a lot to make sure that the Lua VM is sandboxed and can't talk directly to the system unless through sanitized methods.

Draw Tile makes each character a tile in the map. TileMapCache should draw over the existing tilemap as raw pixel data. Can you show me an example or send me the file so I can test out what is going on? All raw pixel data should be drawn above the tilemap. You shouldn't have needed to rebuild the tilemap each frame on the previous version. I'm curious what you are doing because it sounds like you may be drawing the tiles over the text on accident.

Strange, I've seen some issues where it would get stuck in full-screen but you should be able to use Ctrl shortcuts. I'll try to do some more testing. Email me directly at makegames@pixelvision8.com and maybe I can send you a special build that resets the full-screen flag so you can exit out of it.

In a future build, this will be part of the settings screen to get you out. Maybe I'll move that up to the next release.

Oh, that's out of the scope of the engine. I doubt I'll ever have anything like that, it would be overly complicated to implement. Sorry. 

I keep my workspace in a git repo. You could easily keep your entire workspace in one and this way you can track any changes to the Game folder as you build games including the Archive folder where they get saved. You can have multiple Workspaces on your computer. Just go into the settings and paste a path where you want to keep it. I also keep mine in DropBox ;)

This marks the third public release of Pixel Vision 8's Game Creator. Here are the changes since the last release:

  • All new shorthand API designed to help speed up game development.
  • Updated demos to show off new APIs and Pixel Vision 8 features.
  • Renaming archives in the File Picker Tool now correctly update their info.json data.
  • Fixed bugs with saving. You can no longer save when no game is loaded, creating a new game lets you save without renaming first and fixed other issues around not detecting when you can save based on external changes.
  • Fixed how Sprite Tool renders transparent colors to work more like the Color Tool.
  • Fixed display oversample issues which would render 1px of the left and bottom of the screen on the top and right.
  • Sprite Tool now displays tilemap.png tiles that are not in the sprite.png file.
  • Background Color was moved from the Screen Buffer Chip into the Color Chip. Should automatically correct itself when loading up a game and saving it.
  • Add overscan option was added to let you crop the screen, simulate old CRT screen clipping and offer a place off screen to store sprites you don’t want to be displayed.
  • The Clear() method now accepts no values, to redraw the entire display like it previously worked, or you can pass in an x, y, width, and height to clear a specific region.
  • Added a new DrawTilemap method to have more granular control over rendering the tilemap. You can also define an x, y, width and height for how much of the tilemap you want to sample and even define an offsetX and offsetY for where to render it on the screen.
  • Removed ScreenBufferChip. While you can still reference it and its APIs, this will be deprecated in future versions.
  • Backward compatibility exists with the previous APIBridge, but all logic is now routed through the new API. This may cause some rendering and performance issues. The APIBridge will be removed so you are encouraged to migrate over to the new APIs.

Known Issues:

This release took a lot longer than I was expecting. The renderer was completely rebuilt from the ground up to support all of the new features in the tilemap. Because of this, there may be some bugs with rendering, missing functionality and incompatibility with the new APIs. Also, this build included an experimental code preview tool. If you are upgrading, you may not get this tool. A fix is in the works but you can delete your bios.json file and the Game Creator will rebuild the workspace with the latest tools.  Finally, the tilemap tool had several issues. Most of the features have been disabled. While you can still preview a map and scroll around, you are unable to edit like you could in v0.6.x. This functionality will be restored at a later date.

Good news, this update is now compleated. The plan is to launch it towards the end of next week. Now all that is left is some minor bug fixes and updating the documentation.  I've also made sure that current games won't break with the new API allowing you time to migrate your code over when you are ready!

Thanks for your patience and the plan moving forward will be to work on shorter releases to keep updates more manageable.

I appreciate it. Unfortunatly most of the documentation is on my head. I have an automated system for converting google docs into an ebook. It just takes time to write it all down. Each release gets a little bit closer to full documentation. 

Agree, I need to really think through how I would want to support people porting over Pico games. Even with the latest changes, I'm about to push out the two engines have completely different rendering models.

Thanks for sharing though, it's a good start!

So I finally compleated the new API for the next release. The good news is that your game still works as is thanks to the fact that I kept the old API calls in but they are now just routed to the new calls. I was trying to get backwards compatibility so migrating games over to the new calls wouldn't be painful. Once I get the release ready I'll go through and migrate your game to show you how the new APIs work.

Thanks again for this demo, it was a big help when I was refactoring everything!

I agree! The docks have been on the back burner for some time. I need to dedicate a sprite to just getting all of it up to date.

I agree. It's been a struggle to stay true to old hardware but allow some of the cooler stuff I seeing being done with Pico 8. The new API supports pushing raw pixel data to the display as a Sprite (which is capped by the system max sprite limit) or to the tilemap cache which acts like a buffer for rendering the tilemap.

Once I get these new APIs under control I can look into building more helper functions to draw shapes using the existing core drawing APIs.

Ok. My hope is that once I get to beta I can do more to make Linux ports stable. Unfortunately I'm really stuck with Unity's built in support until the C port becomes more stable.

Ok, I believe I can expose that kind of stuff. Let me sort out the new API and I'll see how to fit this in.