nesdev.org

Posted: **Tue Apr 30, 2019 4:23 pm**

There is too much content above for me to follow at this point, sorry. So I'm going to just brain dump.

I told you there were probably typos/mistakes. Good job on finding them. I don't like copy-pasting so the mistakes make sense.

It looks like your tile map and CHR data is correct -- which is great, those tend to be the most annoying -- but the palette may be wonky. Transparency (colour #0) may be part of the problem too, hard to say.

There is no universal palette format. So something named "palette" or .pal means literally nothing. Every program seems to use its own format/model/approach. YY-CHR I believe tends to use an RGB or RGBA format for its palettes, *which are not compatible with the SNES*.

What's important to know is the format of the Super Nintendo CGRAM (palette) data, as its well-understood and well-documented. Each palette entry is 2 bytes (16-bits), with the MSB (top bit / bit 15) unused. The format is 0bbbbbgggggrrrrr, where b/g/r are the intensities of blue/green/red. I explain the format better, with examples, here (see lower half of my post). These are stored in memory/ROM in 65xxx little endian, which means the low byte comes first, followed by the high byte. SuperFamiconv's palette output file are in CGRAM format, which is why you can DMA them directly into the SNES's CGRAM. It's convenient, good, and the right way to do it.

The hex editor you're using is weird. It looks like its batching up the bytes in 4-byte chunks, almost like 32-bit numbers, which means it may be messing with the endian? I'm going to give it the benefit of the doubt and ASSUME it's not. Decoding your colours seems to imply the following, split into their separate B/G/R and MSB sections with commas:

Colour #0 = $7BDE = %0,11110,11110,11110 = almost white
Colour #1 = $0000 = %0,00000,00000,00000 = black
Colour #2 = $0C63 = %0,00011,00011,00011 = a kind of dark grey
Colour #3 = $14A5 = %0,00101,00101,00101 = another shade of dark grey (lighter than colour #2)

And so on... I can see where the differences start though.

Are you 100% certain your palette in each PNG is 100% identical? Placement of colours in the indices, and everything? It see some variance here, but this might just be SuperFamiconv optimising-out unused colours:

Code: Select all

(base) graphics $ superfamiconv -p palette.pal -i frame0.png -t frame0.chr -m frame0.map -v
...
Generated palette with [16,6] colors, 22 total
...
(base) graphics $ superfamiconv -i frame1.png -t frame1.chr -m frame1.map -v
...
Generated palette with [16,9] colors, 25 total
...

You need to make these use the same palette universally. Same colour values, same indices, everything. 100% identical palettes/indices/transparency colour index, everything. I believe that will relieve your problem. If it doesn't, or you're 100% certain the palettes are identical in every way between the two PNGs, then this might just be SuperFamiconv saying "I detected N colours used", in which case, read on:

You might need to use SuperFamiconv's --no-remap flag, which keeps the palette consistent/doesn't remap things. However, to use this flag, you can't just call superfamiconv.exe in one shot any more, you have to use each subcommand individually, and in a specific order. I don't know why Optiroc did it this way, but whatever. So now you have to do a lot of commands to get what was previously done in just two:

Old way:

Code: Select all

superfamiconv -B 4 -i frame0.png -p palette.bin -t frame0.chr -t frame0.map
superfamiconv -B 4 -i frame1.png -t frame1.chr -t frame1.map

New way (so you can use additional flags) -- I sure hope I got these arguments right:

Code: Select all

superfamiconv palette -i frame0.png -d palette.bin --no-remap
superfamiconv tiles -i frame0.png -p palette.bin -d frame0.chr -B 4 --no-remap
superfamiconv map -i frame0.png -p palette.bin -t frame0.chr -d frame0.map -B 4 

superfamiconv tiles -i frame1.png -p palette.bin -d frame1.chr -B 4 --no-remap
superfamiconv map -i frame1.png -p palette.bin -t frame1.chr -d frame1.map -B 4

You can see here what I said above: I'm assuming frame0 and frame1 have the exact same palette (indices, everything).

If this doesn't fix your problem, then please say so. I have a lot more to say about this, including some bugs I found in my animation routine (do not write to $212c outside of NMI!), but this post is getting stupidly long already. I've saved what I've written to a text file, however.

Other comments in passing:

I forget if I mentioned it in the thread, but YY-CHR is not a particularly "good" tool despite its history and socially proliferated belief that it is. Do not even for one second believe that just because a file is named .pal or is called "a palette" that there is some universal standard to this -- there isn't. YY-CHR gives the impression of being a good tool, but is generally "meh". IMO, it's more slated towards NES type work, but it still can't let you manage tilemaps/nametable data, which is very important (esp. in this situation). SNES graphics are likewise not generally compatible with NES graphics, including 2bpp modes. That's just how it is.

Sadly there is not a good graphics editor for SNES in 2019. We had some DOS tools back in the early 90s that did this, but they don't function today. The complication is that the SNES has multiple graphics modes that use different formats of data due to 2pp vs. 4bpp vs. 8bpp vs. mode 7 etc.. Your best bet is to stick with indexed colour PNG as described and use SuperFamiconv.

Please do not use SNES9x Geiger's debugger. This program is flaky and a mess and is unmaintained. Please use bsnes-plus or Mesen-S, both of which are actively maintained. Both emulators/debuggers can show you what the palette looks like in CGRAM, plus give you a hex editor to examine things in real-time. Geiger's debugger is from a time where it was literally all we had available, and we have much better and more user-friendly tools now.

You need to ensure that, in the PNGs, you're:

1. Using indexed PNGs, not RGBA (RGB + alpha) PNGs -- you're using indexed (I can see from the output) -- though SuperFamiconv has support for RGBA, it's apparently wonky/broken in 0.3.1 but fixed in master (see below)

2. Using colour index #0 (i.e. the very first colour in the palette) as the transparency colour -- alpha has no purpose here

3. That you have the PNG configuration set so that colour index #0 is the transparency colour. Just using colour index #0 is not enough, because in PNG (much like GIF) you can say "colour index #xxx is the transparency colour". Make sure all of this is set to use colour index #0.

4. That the pixel at coordinates 0,0 in the picture happens to be the transparency colour. There is a way to override this using --color-zero except that the usage documentation is extremely poor here; this argument takes a value (despite usage docs saying otherwise), and the value is not explained/documented. Picking something it cannot parse results in the program locking up for several seconds then crashing. I think it might be --color-zero #xxxxxx in RGB format, but I'm not sure. I haven't figured this one out yet.

I should note I have used SuperFamiconv with success very recently (2 weeks ago), so I know the program works. However, it's way overdue for a release (GitHub commits indicate it's up to 0.5.x but the last binary release is 0.3.x, and I do see transparency-related bugfixes that have been implemented since. I wish Optiroc would release new binaries already, it's been over a year.

Posted: **Tue Apr 30, 2019 5:32 pm**

koitsu wrote:... If this doesn't fix your problem, then please say so. I have a lot more to say about this, including some bugs I found in my animation routine (do not write to $212c outside of NMI!), but this post is getting stupidly long already. I've saved what I've written to a text file, however. ...

Eh, I finished the write up, so I might as well post it here.

There's one final method you can use to alleviate this issue, which should definitely work: keeping two palettes in ROM (one for each frame), and updating CGRAM with the correct palette per frame. This isn't hard to do, but does change what you do with SuperFamiconv and needs some code changes. Note the filename changes!

Code: Select all

superfamiconv -B 4 -i frame0.png -p frame0.pal -t frame0.chr -t frame0.map
superfamiconv -B 4 -i frame1.png -p frame1.pal -t frame1.chr -t frame1.map

Relrevant code in BANK1 -- note the label name changes:

Code: Select all

frame0pal: .incbin "img/frame0.pal"
frame0pallen = * - frame0pal

frame1pal: .incbin "img/frame1.pal"
frame1pallen = * - frame1pal

Now you need to update your DMA routine to refer to labels frame0pal and frame0pallen... except let's hold off on doing that for now -- you'll see why shortly.

What needs to be added is updating the CGRAM every time you changes frames. CGRAM must be updated in NMI -- it cannot be done outside of NMI for the same reason you shouldn't write to PPU RAM outside of NMI while the screen is on: you risk corrupting the graphics on the screen because the PPU is actively reading data + feeding the electron gun while it draws data. (This is also why me tweaking $212c outside of NMI was a mistake! Late night coding...)

Let's start by making a subroutine that makes DMAing CGRAM updates easier. We'll use some temporary variables in direct page for this. There are "faster" ways, but time is not of the essence in this demo/program, so it's OK. I've added some comments to clarify variable purpose, too:

Code: Select all

bgstatus:    .res 1   ; Written to $212c every NMI; also indicates what current frame we're showing
paletteptr:  .res 2   ; Address (lower 16-bits) of where the palette is in ROM
palettebank: .res 1   ; Bank of where the palette is in ROM
palettelen:  .res 2   ; Length of palette in bytes

The subroutine itself is easy: we already wrote the code earlier, but let's make it more general-purpose and use those variables. This should go AFTER the NMI routine (i.e. after the rti):

Code: Select all

.proc updatepalette
  lda #$00            ; start at colour #0
  sta $2121
  ldx #$2200          ; write to $2122, one byte at a time
  stx $4300
  ldx paletteptr      ; source address: paletteptr contents
  stx $4302
  lda palettebank     ; source bank: palettebank contents
  sta $4304
  ldx palettelen      ; length: palettelen contents
  stx $4305
  lda #$01            ; do DMA
  sta $420B
  rts
.endproc

Now that we have a general-purpose routine, we can use it do to the initial DMA transfer of frame 0's palette at the start (for what gets shown the first time the screen gets turned on). So let's remove that DMA code we wrote for frame 0's palette and replace it with this:

Code: Select all

  ldx #.loword(frame0pal)
  stx paletteptr
  lda #.bankbyte(frame0pal)
  sta palettebank
  ldx #frame0pallen
  stx palettelen
  jsr updatepalette

Now back to updating CGRAM and fixing the $212c bug I mentioned. We'll need to update both mainloop and NMI both, in several ways (I'll explain them at the end):

Code: Select all

mainloop:
  ldy #0
waitnmi:
  wai
  iny
  cpy #60            ; Delay of 60 VBlanks/NMIs (e.g. 1 second) between switching frames
  bne waitnmi

  lda showbg         ; Flip-flop between showing BG1 (frame 0) and BG2 (frame 1)
  cmp #showbg1
  beq show_frame_1

  lda #showbg1       ; Show BG1 (frame 0)
  sta bgstatus
  ldx #.loword(frame0pal)
  stx paletteptr
  lda #.bankbyte(frame0pal)
  sta palettebank
  ldx #frame0pallen
  stx palettelen
  bra next

show_frame_1:
  lda #showbg2       ; Show BG2 (frame 1)
  sta bgstatus
  ldx #.loword(frame1pal)
  stx paletteptr
  lda #.bankbyte(frame1pal)
  sta palettebank
  ldx #frame1pallen
  stx palettelen

next:
  jmp mainloop

.proc NMI
  pha
  phx
  jsr updatepalette
  lda bgstatus
  sta $212c
  plx
  pla
  rti
.endproc

Changes:

- Switched to using the Y register for the frame counter. This because our main loop is now "trashing" (using) X for populating paletteptr and palettelen. We could've used phx/plx around that code, but since we have an indexing register that isn't being used, might as well use it. If Y gets used in the future, the best approach to take is to have NMI increment a 16-bit variable in DP/RAM and then refer to that variable outside of NMI

- Don't write to $212c in the main loop (outside of NMI while the screen is on = bad)

- Renamed label show_frame_2 to show_frame_1, since it's more in line with starting-from-0 frame counts

- Use jmp mainloop instead of bra, in case our main loop gets too big for relative addressing

- Change paletteptr/palettebank/palettelen every time we switch frames, pointing to the proper palette data in ROM

- NMI: Make use of .proc/.endproc (code clarity)

- NMI: Backup and restore A/X registers since we'll be using both

- NMI: Update $212c based on bgstatus

- NMI: Call updatepalette subroutine, which does a DMA transfer to CGRAM (starting at colour #0) based on the contents of paletteptr/palettebank/palettelen

What this means is that NMI will update CGRAM *every single frame*, regardless if there are changes or not. I feel this is acceptable for this kind of demo/program, plus the palettes are not particularly big (for 16 colours, 32 bytes), and there's more than enough time left in VBlank for other things.

If you wanted to change NMI so the jsr only happens when there's an actual frame change, that's pretty easy: just use a variable to track if there's a change (e.g. if set to 1, do the jsr + set it to 0, all in NMI), and set it to 1 in the main loop where/when appropriate.

There are tons of other optimisations you could do too, but for what this demo/program is it's really not worth it. But if you feel so inclined, go for it.

Posted: **Wed May 01, 2019 10:10 am**

I’m working on SuperFamiconv again now, and it sounds like I should add the “no-remap” flag to the one shot operation too...

No particular reason why it isn’t there, except that I tried to keep it simple for people just to get a piece of graphics out of it with a minimum of hassle. The “power user” modes are best used by means of scripting. I should provide some “asset pipeline” makefile examples.

Posted: **Fri May 03, 2019 2:41 am**

I added --no-remap to the "one shot" superfamiconv command mode.

As far as how the tool is meant to be used, I made this diagram before writing it.

The key difference between most other tools is that all inputs can be RGBA8888 images and the tool will take care of remapping. And if further control is needed, the idea is to use a carefully authored palette as "truth", and then both tile and map image inputs can still be truecolor images and the tool should be able to map it to the palette.

Posted: **Fri May 03, 2019 3:43 am**

Any chance of Windows x64 binary releases of these tags being made? AppVeyor is something you could use for automation of such builds, and it's free for public open-source projects, plus includes CMake.

Posted: **Fri May 03, 2019 8:37 am**

I finally got it all to work, thanks for all the help!

I couldn't get the one palette solution to work correctly, so I just made two different palettes that I swap out during VBlank.

Here is what my full code looks like for reference:

Code: Select all

.define ROM_NAME "TEST"
.include "lorom128.inc"


.segment "BANK1"

palette0: .incbin "img/frame0.pal"
palettelen = * - palette0

palette1: .incbin "img/frame1.pal"


.segment "BANK2"

frame0map: .incbin "img/frame0.map"
frame0maplen = * - frame0map

frame0chr: .incbin "img/frame0.chr"
frame0chrlen = * - frame0chr


.segment "BANK3"

frame1map: .incbin "img/frame1.map"
frame1maplen = * - frame1map

frame1chr: .incbin "img/frame1.chr"
frame1chrlen = * - frame1chr

zerobyte:   .byte   $00

counter_limit = 50


.segment "ZEROPAGE"

bgstatus:   .res    1
counter:    .res    1

init_bg = %00000001
bgmask  = %00000011


.code

Reset:

    Init_Snes

    ldx         #$0000
    stx         $2116                   ; Zero-initialize VRAM via DMA
    lda         #%00001001
    sta         $4300
    lda         #$18
    sta         $4301
    ldx         #.loword(zerobyte)
    stx         $4302
    lda         #.bankbyte(zerobyte)
    sta         $4304
    ldx         #$0000
    stx         $4305
    lda         #%00000001
    sta         $420B

    lda         #$00                    ; Set BG1 tile map at VRAM $0000-07FF, 32x32
    sta         $2107

    lda         #$08                    ; Set BG2 tile map at VRAM $1000-17FF, 32x32
    sta         $2108

    lda         #$41                    ; Set BG1 CHR at $2000 and BG2 CHR at $8000
    sta         $210b

    ldx         #$0000                  ; Copy BG1 tile map to VRAM at $0000 via DMA
    stx         $2116
    ldx         #$1801
    stx         $4300
    ldx         #.loword(frame0map)
    stx         $4302
    ldx         #.bankbyte(frame0map)
    stx         $4304
    ldx         #frame0maplen
    stx         $4305
    lda         #$01
    sta         $420B

    ldx         #$0800                  ; Copy BG2 tile map to VRAM at $1000 via DMA
    stx         $2116
    ldx         #$1801
    stx         $4300
    ldx         #.loword(frame1map)
    stx         $4302
    ldx         #.bankbyte(frame1map)
    stx         $4304
    ldx         #frame1maplen
    stx         $4305
    lda         #$01
    sta         $420B

    ldx         #$1000                  ; Copy BG1 CHR to VRAM at $2000 via DMA
    stx         $2116
    ldx         #$1801
    stx         $4300
    ldx         #.loword(frame0chr)
    stx         $4302
    ldx         #.bankbyte(frame0chr)
    stx         $4304
    ldx         #frame0chrlen
    stx         $4305
    lda         #$01
    sta         $420B

    ldx         #$4000                  ; Copy BG2 CHR to VRAM at $8000 via DMA
    stx         $2116
    ldx         #$1801
    stx         $4300
    ldx         #.loword(frame1chr)
    stx         $4302
    ldx         #.bankbyte(frame1chr)
    stx         $4304
    ldx         #frame1chrlen
    stx         $4305
    lda         #$01
    sta         $420B

    lda         #init_bg                ; Enable BG1
    sta         bgstatus
    sta         $212c

    jsr         Update_Palette          ; Copy palette to CGRAM via DMA

    lda         #$01                    ; Use graphics mode 1
    sta         $2105

    cli                                 ; Enable interrupts

    lda         #$80                    ; Enable VBlank interrupt
    sta         $4200

    lda         #$DE                    ; Set background color to "white smoke"
    sta         $2122
    lda         #$7B
    sta         $2122

    lda         #$0F                    ; End force blank
    sta         $2100

    lda         #counter_limit          ; Initialize counter
    sta         counter

@Loop:
    wai                                 ; Wait for NMI
    jmp         @Loop


Empty_Handler:
    rti


Update_Palette:
    lda         bgstatus                ; Check which palette to load
    cmp         #$01
    bne         @LoadPalette1

    ldx         #.loword(palette0)      ; Load palette0
    stx         $4302
    lda         #.bankbyte(palette0)
    sta         $4304
    bra         @Continue

@LoadPalette1:
    ldx         #.loword(palette1)      ; Load palette1
    stx         $4302
    lda         #.bankbyte(palette1)
    sta         $4304

@Continue:
    lda         #$00                    ; Copy palette to CGRAM via DMA
    sta         $2121
    ldx         #$2200
    stx         $4300
    ldx         #palettelen
    stx         $4305
    lda         #$01
    sta         $420B

    rts


NMI:
    lda         counter                 ; Update counter
    sbc         #$01
    sta         counter

    cmp         #$00                    ; Toggle background when counter reaches 0
    bne         Exit_NMI

    lda         bgstatus                ; Toggle background
    eor         #bgmask
    sta         bgstatus
    sta         $212c
    jsr         Update_Palette

    lda         #counter_limit          ; Reset counter
    sta         counter

Exit_NMI:
    rti

Posted: **Fri May 03, 2019 2:42 pm**

Here's a binary release of the current version of SuperFamiconv (v0.7.1).

I appreciate any bug reports and feedback, since I've changed lots of things and don't have proper test data in place for all functionality yet.

Posted: **Fri May 03, 2019 3:44 pm**

Nicely done!

And big thanks to Optiroc for providing updated SuperFamiconv binaries and making use of AppVeyor**. The program is fantastic and incredibly important for doing SNES graphics; an invaluable tool when combined with good-quality PNG editors (I've been using Aesprite, which is good but not great).

** - You might also be interested in CirrusCI or TravisCI, though they're more *IX-based, so cross-compiling binaries for Windows on Linux/BSD would be involved. Not sure what's involved in all of that; I tend to build binaries natively on the OS they're intended for. I've had wonderful success with CirrusCI as a free-for-OSS-projects service allowing me to ensure my commits build on several versions of FreeBSD. They all have tie-ins to GitHub natively in one way or another.

Posted: **Fri May 03, 2019 6:34 pm**

Wow. This could be very big. Sorry I didn't notice it before.

Converts and PNG to SNES optimized palette, tileset, and tilemap. (Also, GBC, optionally).

The readme could be slightly more... I don't know, tutorial ish. With pictures of examples.

Posted: **Sat May 04, 2019 5:51 am**

Super Famicomv gives me an application error (Win 7 Pro x64): unable to start correctly (0xc00007b). Any idea what that is about?

I'm interested in using this program for SNES graphics, but mainly for PCE as well, as there aren't a lot of good tilemap optimizing programs for the PCE/Turbografx. To that end, is 16 subpalettes possible in your program, or is the default of 8 the maximum option?

Posted: **Sat May 04, 2019 11:53 am**

ccovell wrote:Super Famicomv gives me an application error (Win 7 Pro x64): unable to start correctly (0xc00007b). Any idea what that is about?

Not really, but maybe I should build with stdlibc++ statically linked. I'm not sure how this all works on Windows though - I seem to remember that you get a fairly nice warning message if not a suitable C++ runtime is installed. Anyway, I changed the build environment to the less bleeding edge Visual Studio 2017, please try if it works better:
https://ci.appveyor.com/project/Optiroc ... /artifacts

ccovell wrote:I'm interested in using this program for SNES graphics, but mainly for PCE as well, as there aren't a lot of good tilemap optimizing programs for the PCE/Turbografx. To that end, is 16 subpalettes possible in your program, or is the default of 8 the maximum option?

It is the maximum at the moment, but I've thought of leaving most parameters unconstrained. If you set something explicitly you probably have good reason to, I figure. It is really only when exporting binary map data you want to make sure that there's not more palettes than the map structure allows, for example. I'll change that!

I'd also love to add proper PCE support. I've never done anything with that system, though. What would be the best documentation of its palette/tile/map structures?

Posted: **Sat May 04, 2019 2:31 pm**

Optiroc wrote:I'd also love to add proper PCE support. I've never done anything with that system, though. What would be the best documentation of its palette/tile/map structures?

The official development documents are good I think.

Posted: **Sun May 05, 2019 6:04 am**

Optiroc wrote:I'd also love to add proper PCE support. I've never done anything with that system, though. What would be the best documentation of its palette/tile/map structures?

If it's background tiles only, the PCE is very simple. 64K of VRAM and the same 4bpp tile format as the SNES. Each 8x8 tile can have one of 16 subpalettes, and there is no tile flipping. Tile maps can be 32x32 characters up to 128x64, in increments of 32 chars, of course.

From Charles Macdonald's in-depth doc: https://github.com/asterick/TurboSharp/ ... cetech.txt

Code: Select all

The background itself is defined by the block attribute table (BAT), which
 starts at address zero in VRAM. Each word-wide entry in the BAT defines
 a single character, and has the following layout:

    MSB          LSB
    ppppnnnnnnnnnnnn

    p : Color palette (0-15)
    n : Character name (0-4095)

Because the TurboGrafx-16 only has 64K of VRAM, only patterns 0-2047 should
be used. Patterns 2048-4096 are filled with 'garbage' data.

The palette format (3 bits per colour component, 16 subpalettes of 16 entries 2 bytes each) is also simple:

Code: Select all

MSB          LSB
-------GGGRRRBBB

Posted: **Mon May 06, 2019 11:53 pm**

ccovell wrote: I'm interested in using this program for SNES graphics, but mainly for PCE as well, as there aren't a lot of good tilemap optimizing programs for the PCE/Turbografx. To that end, is 16 subpalettes possible in your program, or is the default of 8 the maximum option?

You already have a similar tool for PCE made by Orion,but this tool is limited to 1 sub palette and support only .bmp files :
http://onorisoft.free.fr/pce/bmp2pce.zip

BMP to PC Engine v0.4

by Orion_ [2007-2010]

http://onorisoft.free.fr/
onorisoft@free.fr

This tool allows you to convert a 16 colors (4bits) BMP into PC Engine Graphic Data and Palette.

It support Background tile mode (BG/BGRAW) and Sprite Mode (SPR).

For the background mode (BG), the tool automatically remove the duplicated tiles and create a ready to use tile map / bat file.
You can also use the BGRAW mode to disable the duplicated tiles remove and map creation. It will then just convert your BMP as a RAW Tiles Gfx.

You can also specify a VRAM Address Base for the tiles and a Palette index base.
The default base VRAM Address used is 0x1000.

Usage: bmp2pce <BG|BGRAW|SPR> <bmp_file> [options]

Examples: bmp2pce BG bg.bmp [tile vram address (hex)] [palette number (dec)]
bmp2pce BGRAW bg.bmp (no map is exported, the bmp is converted raw)
bmp2pce SPR sprite.bmp

Posted: **Tue May 07, 2019 1:18 am**

I’m finishing up full PCE support tonight, probably.

nesdev.org

How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?

Re: How to show graphics on the screen?