itch.io

Ah that would be the issue, the problem is I was downloading via the "Install" button on the Itch store, it never gave an option between Mac or PC, I found my way to your main page where I did indeed find the option for downloading the windows zip :)

Cheers, will give this a shot.

Wont install on Windows

Checked the file it downloads and its extension is .dmg

Sounds good to me, I look forward to seeing this develop, its shaping up quite promising.

For tile maps I am certainly out of my depth but if there are for arguments sake 255 tiles could you not save them into hex files?

A lay out of 00-FF in each 'cell' then read that file with a 'for each' style function and it loads the tile based at the currently read byte from top left to bottom right. 00 = nothing, 01 = Tile 1, etc.

I think this is why many game dev programs keep their bg tiles seperate from the sprites so it has a dedicated starting place to look and use them from the graphics 'ROM'.

And obviously to save tile maps it would just read from the users current mapping layout of their dedicated map tiles, starting top left and write them into a new hex file (.map could be the arbritrary extension) until it finds the end of a horizontal line and inserts an FF then continues to read on the next vertical line and writes them to the file and on the last vertical line when it reaches the last readable tile and cant go to the next vertical it will return a null thus ending the writing to file.

With this is you would use a 2 byte as a queue signal of an 'end' so it knows to start a new line.

It could be 00 as blank tile and FF as the new line byte which I will use here for the reading from file example.

imaginaryfile.map

00 01 00 05 00 00 29 00 00 00 FF 02 EA 00 04 19 00 00 00 00 00 FF 08 07 13 05 05 05 00 00 55 00 FF

This would read from the file and start drawing from the top left (0,0 in the world):

Blank tile, tile 001, blank, 005, blank, blank, 041, blank, blank, blank, (FF) New Line>

Tile 002, 234, blank, 004. 025, blank, blank, blank, blank, blank : New line>

Tile 008, 007, 019, 005, 005, 005, blank, blank, 085, blank, New line>

Finds null = End read/write

So the map would look like this:      __ = 8 pixel blank tile

__ 01 __ 05 __ __ 29 __ __ __

02 EA __ 04 19 __ __ __ __ __

08 07 13 05 05 05 __ __ 55 __

The user wouldn't have to put in tiles '00' or 'FF' (tiles 0 and 255) to mark a blank or the end of a horizontal line, when its writing to file it would detect the end of a horizontal line (returns null at the map border) and automatically puts in an FF and if it detects anything but a users tile it would place a 00 in that byte address.

On the users side they would be able to use Tiles 001 to 254 for their own sprite work (this is assuming you use a 2 bit per tile here).

It then triggers a 'new line' boolean to check the first byte of the new line, if its <FF then it continues else it returns a null and thus 'done' to trigger the end of the for/each loop.

Create Map (in the editor)

MapH = 20

MapV = 15

This would automatically write into memory 15 lines of 00 with every 21's byte (2byte) being assigned FF

As the user places tiles it puts them in the relavant byte locations.

Saving the file transfers the memorised layout to an actual file,map

I hope I made sense with that, I'd be happy to try to explain it a little better if need be.

I dabble a little with programming here and there (little experiments) so tried to think it through logically from a programmers perspective.

Alternatively you could not have dedicated background tile maps and just use ANY of the tiles...

FF would limit your sprite count to 256 but FFF would be a wealthy 4,096 limit, with 000 being used for a blank and FFF being used as a new line call this leaves the user 001 to a whopping 4095 sprite tiles to play with for map, character, frames of anim, enemies, items, etc .

This way you could also place enemies and items on the map too as each tile could have its own unique features and affects on the game world.

FFFF is probably overkill with a staggering 65,536 options - 2 for the blank and end line call.

Another alternative would be to set the width and height in the first few bytes of the file and then the FF new line insert would be irrelevant as it would automatically start a new line anyway.

This is probably better and more 'professional' anyway, it also would reduce file sizes a few bytes for the maps and make it easier to code.

Assuming we use a 2bit layout.

00 0A 00 03 00 01 00 05 00 00 29 00 00 00 02 EA 00 04 19 00 00 00 00 00 08 07 13 05 05 05 00 00 55 00

First bytes: 00 09 00 02 (depending if you use Big endian or little Endian) would be 0010 (0=1) in width and 0003 in height. (0000).

Then we stream the bytes in 00 03 01... etc and every time it gets to the 09 (10th) it returns to 0 on the x and increments on the y for the height, continues to stream in the data and assigns them to the next row until both the width and height have been met.

Here's a VERY primitive code theory of the for loop, I'm sure you know how to put this into practice cleanly.

>        if x < width and y < height

>        'read next 2byte, use tile number returned to draw into the current cell, advance to the next cell,

>       x = x + 1

>       if x = width: y = y + 1 and x = 0

>      if y = height: end the loop, close the I/O.

OK cheers for the heads up.

As the title suggests, it could work similar to Asesprite or almost any art package whereby you can import the colours as a palette swatch to then save for future use.

I have plenty of suggestions but I'm trying to keep them to the basic bare bones needs (on top of the general release full functionality).

May I also suggest considering a cell colour limitation mode, for this you would have to think of 8 bit machines or less which would only allow for a set number of colours in any one cell, famously a feature for the ZX Spectrum for example where colour bleed would be common.

The NES also only coud have 4 colours per tile/cell, It would be great to be able to replicate these limitations.

Screen dimensions 15x12 = 5:4 ratio.

Not even Wide screen BOOOO.

Obviously joking, this has however given me a fun idea which I want to credit your good self with and give you first dibs.

A 16:9 game jam, when people hop on to expect this to mean 1920x1080 imagine their faces when they find out its literally 16x9 pixels to make a game :P

If that doesn't get any takers it could always be bumped up to 32x18 or 64x36.

Then create a scene like this one with an area to overlay the borderless wind of the game so it looks much like this scene but square on rather than isometric as that would be easier to program for.

If it had to be at an angle some engines allow 3d projection which would give them an advantage unless strict rules were put in place that 3d projection wasn't allowed? I dunno, would just be fun to see what people could achieve with such a tiny resolution.

Anyway think it over, would be fun and a cool little lowres challenge.

Python 2.7

It loads up, I can then scroll through the menus but if I try any button (z,x, F buttons) I get this..

Windows 10 64bit, Intel i7 3770, 16gb ram with Nvidia 1070gtx

I'd love to give this a blast but I simply can't do anything with it.

Pressing any key that may do something other than cycling the main menu of cartridges with left and right cursors results in a crash :/

I love this style, the tinier the better :P, Do you use a perticular palette (pico-8 for example)?

Love to look through pixel art and notice you have a particular style that appeals to me and if I were to use any of your sprites I would like to be able to expand on your style with the same palette.

Oh and "Credit is not necessary" that is very admirable to see when there are so many people who spend far too much time chasing credit, take downs or even legal action in some cases. However I would suggest if someone creates a game and has credits to at least pop the creators name under the graphics/art section out of respect.

I'd love to see a Love tutorial to see how to get a little platformer scene up and running (even just a single scene with no enemies, I have no clue where to start with Love even trying to follow tutorials, there seems to be a gap of steps to take to get things rolling in every tutorial that just leaves me clueless lol.

Just a quick question purely out of interest.

The resolution you went with is 240x136, I was wondering why you chose 136 rather than 135 for a true 16:9 ratio which would be 1920x1080/8?

Is this purely down to being able to fit the tile maps 8x8 on the screen without losing a line of pixels?

I'm assuming in full screen mode it would just display the bottom row of true pixels in 8x7?!

Were you tempted to go to 256x144 for a 16:9 and divisable by 8 choice? Or even a ratio like 4:3 or 5:4.

Sorry if they seem like irrelevant questions, I just have curiosities on inspired choices made and what ideas you toyed with.

Anyway please keep up the great work, I hope you consider increasing the size limit of the cart to allow creations to be a little more ambitious, I like the idea of restrictions but I'm a bit put off by the idea that a full 8 bit demake or port is pretty much out the question for anything of significant content (Mario 3 with a save feature is always my imaginary rule of thumb for 8 bit).

And even if you felt like being extra generous with the limits...well...

(240x136 using pico-8 palette)

Thanks for the reply.

I reinstalled the current (unstable) build.

I found the rescale feature and x4 is perfect for me.

I did notice the sound editor is broken in this build now however, but I'm guessing this is part of the issues with this build you mentioned and on top of that for the next update, I do enjoy the simplicity and the random feature, it offers inspiration for creating some interesting melodies.

I am excited to see how this program pans out, I've had fun using Pico-8 but fast becoming worried that I am picking up bad programming habits because of its often arbritrary restrictions, I like restrictions to stay focused but its really not realistic to claim to be replicating 8 bit consoles but you can't create much more than a small demo or very minimal game unlike what real 8 bit consoles can achieve.

Anyway the reason I mention this is that I am hoping this is where Game Creator Pro (why not "Pixel Vision 8" btw?) corrects things, so far its looking very promising, I really hope the Code Editor will be a full Editor, even if all it is doing is acts as a notepad++ style editor, it would be better than just a previewer, being able to do everything within the one program is very comfortable, this is what Pico-8 did get right, even if you do need to have reference pages open at the side, its still good to know you could technically do everything from start to finish in one piece of software.

I'd say a good rule of thumb would be that using the preset for the console you choose it should be able to achieve what the console could, so for NES that would be Mario 3 as I believe that was a game that pretty much peaked the consoles limits. not sure what the other consoles limit pushing games were, but to be able to get all levels, music tracks, sound effects and sprites squeezed in then mission accomplished.

Please consider a video dev diary on youtube to keep us posted on progress and feedback and suggestions from the comments could help you along if needed, if you aren't a fan of talking just some screen caps and pop up text pointers of what you are showcasing would be fine.

I look forward to seeing what your late September update brings, keep up the good work, I will be watching this one.

- Imp

I dont see the pro features in the beta build is this normal?

I use Itch so I get the auto update feature, however I have to use the stable build otherwise the pro features aren't available and I can't scale the window.