8bit Game Maker

[Tisa]

thegist of it is that pxon is pixel art represented in JSON. the current session of your drawing should be represented in the textarea below - paste into a .json file or app that supports pxon for good fun!

note: pxon is a draft proposal and a fake idea by me (jenn, creator of make8bitart.com) that's being updated sporadically and sometimes doesn't work. please let me know if it's broken!

Jsfxr is an online 8 bit sound maker and sfx generator. All you need to make retro sound effects with jsfxr is a web browser. It's a JavaScript port of the original sfxr by DrPetter. You can also use it as a JavaScript library for playing and rendering sfxr sound effects in your games.

Basically the main limitation of NESmaker will be that you can only create what is available within the program itself. If you are a NES programmer with tons of knowledge on the system, you might actually find this program quite limiting, as you will essentially be limited within the constraints of the program that has been created. Fortunately there will be the opportunity to manually edit the code, but that will be pretty much like reverse engineering a NES game which is another beast in and of itself.

However, if you are like me and a passionate hobbyist that has always wanted to create a NES game from the ground up, but the nuances of assembly coding is way too overwhelming (which I think is a majority of us), NESmaker is absolutely perfect!

With the program also comes the Mapper and board limitations. The games will essentially allow for flash saving and use a unique mapper to do this, which is currently only available from a couple of individuals (InfiniteNESLives and RetroUSB off the top of my head) and are not the most affordable boards available for the NES. That means that if you want to actually distribute your NES game it will cost quite a bit (think board costs, plus cartridge, label, sleeve, then Box, manual, styro if you are going CIB).

Hello

I need to creat a litle bmp image for a graphic discplay KS0108.I was looking in the exemples of the glcd v2 library but I cant find a easy way to build the image.h which contains an array with the bitmaps of a bmp.How can I just drow a simple image on paint and then convert that small image to display on display?

Any help

Thanks for your time

The the glcd v3 library comes with a tool to do the bmp to .h conversion for you.

It comes with a java app down in glcd/bitmaps/utils/java.

Unfortunately, there are a few issues with Nautilus

on Ubuntu (which based on your avatar and signature I assume you are running).

Nautilus does not set the current directory to the currently selected/viewing directory.

I as well as many others consider this a bug, the Nautilus maintainers do not consider

this a bug and say that no program should make assumptions as to the current directory

when started. (other tools don't take this view)

That issue can be worked around. But there is also some kind of drag and drop

JAVA issue when used with Nautilus that we have not been able to work around

which prevents the java app from being able to get the bmp file for conversion.

It does work on Windoze, so if you are willing to use Windoze you can fire up the java app and then simply

drag and drop the bmp file into the java app window and it will do the conversion

to a .h header file and update the appropriate header files under glcd/bitmaps

Download BMP bitmap to GLCD bitmap for free. Command line tool to convert BMP images to binary bitmaps and c header files with 8bit page layout instead of line layout (one byte is 8-bit vertical line). Can be used to present data for graphical LCD...

Blast from the past. It had been a long time since I looked at that.

After going back and carefully reviewing the data formats,

it does appear that the pixel ordering and byte ordering is the same. However, (before my time on the glcd library)

the glcd library deviated slightly from the XBM format in order to make it simpler to use bitmaps.

The format of the data was modified to include the size information as well as the bitmap data.

This allows the bitmap API to use a single/simple pointer to a bitmap and not have to pass around the sizing

information.

So it appears that the only difference between the bitmap format that the glcd library wants

and XBM format is that that the first two bytes of the glcd library data array represent width and height.

It wouldn't be that difficult to write a perl or awk script to modify an XBM file header into a glcd library bitmap header.

It has to insert the width and height into the data array and also change the declaration to use PROGMEM.

Ok in actually going and looking even closer at the XBM format along with the library bitmap rendering code,

I realized that the XBM format is not compatible with the existing bitmap rendering.

The existing bitmap format in the bitmap headers is stored in the exact same format as GLCD memory:

Top to bottom and left to right.

XBM format is stored in the bytes the same way a CRT paints pixels. From left to right and top to bottom.

While both formats have their 0,0 origin in the upper left corner, they don't map the pixels in

the data array the same way.

If you would like to be able to draw XBM bitmaps on the glcd,

here is a working example of a rendering routine that can render XBM bitmaps on the glcd display:

While it isn't optimized for speed since I tossed it together in just a few minutes, it does perform

acceptably well.

This routine can be tossed directly into your sketch. It would require changing the declaration of the array

in the .xbm file to have a PROGMEM but that is all.

This routine does not assume the width & height are part of the data like the existing DrawBitmap()

and you call it directly by name DrawXBM() rather than GLCD.DrawXBM()

bperrybap:

Ok in actually going and looking even closer at the XBM format along with the library bitmap rendering code,

I realized that the XBM format is not compatible with the existing bitmap rendering.

The existing bitmap format in the bitmap headers is stored in the exact same format as GLCD memory:

Top to bottom and left to right.

XBM format is stored in the bytes the same way a CRT paints pixels. From left to right and top to bottom.

While both formats have an their 0,0 origin in the upper left corner, they don't map the pixels in

the data array the same way.

I guess my description may have been a bit misleading/wrong. The GLCD format isn't really top to bottom

and then left to right. It is left to right but 8 pixels high at a time.

(The 8 pixels are top to bottom)

So it isn't as easy as flipping the image. Flipping the image does not alter how the image pixel data is stored in the byte array.

flip and flop only transpose the image data but not the format of the stored pixel data bits.

Even if the image is flipped, the pixels will still be stored left to right 1 pixel at a time

from the right edge to the left edge and then top to bottom instead of left to right 8 pixels at a time.

The dilemma is that both formats store pixel data from left to right but not by the same amount in height.

The XBM format moves from left to the right of the image 1 pixel height at a time while

the glcd format moves from left to right with a 8 pixel vertical "page" height at time.

glcd format does not paint top to bottom of the full image 1 pixel wide and then go left to right.

glcd paints an 8 pixel tall path from left to right.

So each byte in XBM is 8 pixels in a 1 pixel tall row until you hit the right edge of the image, while with GLCD

each byte is 8 vertical pixels tall until you hight the right edge.

So what happens if you attempt to interpret the XBM format as glcd format,

is that the second byte of data will draw 8 vertical pixels just the right of the first 8 pixels rather than below

the first 8 pixels. So the image isn't just rotated, it is all scrambled.

The only way to fix this is to interpret the XBM data differently than the glcd format data.

Had glcd format drawn from top to bottom of the image then gone left to right, the image data would

have worked, it would have just been rotated. The reason they went left to right 8 pixels at time

for glcd format is that is the optimum way to write to the display for speed.

Makerfabs focus on small batch PCB, PCBA solutions and provide efficient, high-standard services. We offer turnkey service for makers & start-ups to create the first prototyping board to mass production, including PCB, components sourcing, PCB assembly, soldering, programming, testing, case design, 3D printing, CNC, molding injection, packing & shipping, etc.

Actually, I received error-free, original images of all disks in PM from @GoodByteXL. These were subsequently made available on my website. I just never stated these facts directly in the thread. What was never confirmed there was whether the "Software Preservation" copies were error-free or not.

Of course, in this day of atr images Megabytes in size, and storage media being so cheap, so that we can store an almost unlimited amount of disk images without needing to purchase diskettes, I don't know that there's really much need or use for multiboot disk menus anymore, other than nostalgia, of course.

RobC DiskeyII/Muscial Menu Maker: - you could add a game tune to the menu, it plays during initial menu load (until a menu item is selected). Adding a musical menu (I think) resulted in one less menu option on the main screen.

Do you have a list of all of them? I was working on a disk cataloguer years ago that would read the contents from several DOS and Menu disks. Would be interesting to see which ones I missed. One I was about to add before life got in the way was the Alpha menu.

These Alpha-Load menu disks work on the various emulators and work perfectly well under 800XL/130XE emulation etc but you may need to change the disk emulation settings in some of the emulators. They also work on real hardware as long as the 1050 drive has been hardware upgraded with a US Doubler / Happy 1050 / Speedy etc modification.

3a8082e126