New adventure game project

[whartung]

GARTHWILSON wrote:

djangojames wrote:

What is the MTTF for an SSD? It was about four years old...

I've seen a lot of first-hand reports on the forums of SSDs not lasting very long. I'm not ready to depend on one until the durability is improved. For now, we do have quite a system of daily automatic backups here at home (to mechanical hard discs), thanks to our son's server in the garage. It also has its own backups. It's just better to not need to go through the process of restoring everything though.

My oldest SSD is, I think, pushing 6 years old. It's my work machine. I run databases, do source code builds, other generic data processing on it.

Only failure I've heard of here at the office was the one in the laptop of a guy in our analytics group, and he was constantly reloading very large databases.

Most of our main production filers are now SSD as well. We have TBs of the things.

I back up to a regular hard drive (Mac OS Time Machine), but that's more simply because $$/byte is better than SSD, and performance is secondary. I would like to get rid of it, though, simply because the machine does a hard stall when the drive spins up.

At home I have 2 SSD in my machine, plus a hard drive backup. My wife's laptop is SSD, and she backs up to an SSD. Form factor wins there. It's basically a thick credit card that she plugs in every couple weeks.

Modern SSDs with modern OSes are much better at spreading the load out on the devices, giving them great working life.

[unclouded]

djangojames wrote:

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/raw/master/kerning.png

The fifth one down is very nice indeed.

I have some 30-odd SSDs, mostly in the data centre and have had two failures in the last ten years, one 30GB ADATA mSATA device and one 160GB Intel 320 series. Over the same period I've had 2x Seagate HDDs and 1x WD HDDs fail, not that any of this is statistically significant. At least it's easier to get vendor diversity in the SSD arrays, although I have to pay attention to vendors re-badging the same chipset.

Backup is automatic daily (pull SSH) to a ZFS pool with daily snapshots going back 12 months, so I can pull the state of any file within the last year. ZFS zero-cost snapshots rock. And on-line de-duplication if you have the RAM: I've 16 GB allocated to the backup server and a dedupratio of 2.93x.

[White Flame]

BTW, if you added more vertical spacing between lines of text, it would make the non-consistent-baseline font much easier to read.

[djangojames]

I am now wondering if the SSD failed because of my misunderstanding of how mmap works- I have never had a HDD fail before in 20 years, guess I have been lucky.

Here's the same text in the two other fonts, thanks for all your suggestions.

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/yeolde.png?raw=true

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/future.png?raw=true

[GaBuZoMeu]

Both screens are ways better to read than the previous ones.

I would suggest choosing the upper screen font when your adventure is an ancient fairy tale or s.th. related to knights and trolls etc.
The lower screen font would nicely fit to some space_star_challenge_war_adventures me thinks.

[djangojames]

So I had my first go at images! Woo. No 6502 compression yet, that's next on the list. For now just experimenting with converting images to use...

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/conversion.png?raw=true

https://github.com/djangojames/explorat ... er/blog.md

GaBuZoMeu, Yes that gothic one is ace. I found it on a bitmap font editor website (and heavily edited it to fit 8x10 pixels). I need to find and credit the original designers. You've spotted the central theme of the game... trolls AND spaceships...

[djangojames]

And more,

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/porsche.png?raw=true

[djangojames]

Final images... I promise. Next I will post some actual 6502- I'm going to move onto image compression. Is there a section for this, or should I just keep posting here? What I really need is some of you assembler wizards to critique the number of cycles I am using...

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/gasstation.png?raw=true

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/maxine.png?raw=true

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/stairs.png?raw=true

I'd love to see how these look on a real C64 on a flaky old CRT TV. I aim to have this running on VICE or similar, but to enter the IF competition I will build a simplified 6502 emulator in JS so it can run in the web- with only the minimum graphics and I/O I need. I might not get round to making the code actually run on a real (or real emulated) C64. Having said that, I am not doing anything to preclude it.

https://github.com/djangojames/explorat ... er/blog.md

[GARTHWILSON]

djangojames wrote:

I'm going to move onto image compression. Is there a section for this, or should I just keep posting here?

I would be interested to see 6502 discussion on image compression, in the "Programming" section. Making it to be general-purpose might attract more readers than it would be if it appeared to be specific to video games. Be sure to post a link here to the new discussion.

Garth (moderator)

[djangojames]

Thanks Garth

I have begun jotting down my thoughts on it here, https://github.com/djangojames/explorat ... er/blog.md

I will post something to the Programming section when I have some code to show.

[White Flame]

djangojames wrote:

I'd love to see how these look on a real C64 on a flaky old CRT TV.

Yeah, the current scanline rendering in the posted images is way too harsh, as the lines should have some glow around them and not be stark black between 2 bright lines. It'll look a lot better even in VICE with its CRT emulation. (that is, unless the output is actually putting alternating black pixel lines on the c64 display, which will retain the harsh look)

However, when it comes to converted graphics, remember that 320x200 on a 4:3 display does not yield square pixels, so things will look more stretched on the real thing. Shrinking it down to 267x200 for modern square-pixel displays would give the same pixel aspect as a C64+CRT (or double it up to 640x400, then shrink to 533x400 for scanline-style display).

[djangojames]

Thanks, that's useful information. The black scanlines are part of the my renderer, so reducing the harshness should be straightforward (half bright alternating lines?) Scaling to a non-integer aspect ratio may be trickier with the code I have- it's just a simple blit at the moment. I'll have a look at the VICE code to see how they do it- they probably use some tricks to speed things up. I imagine each rendered pixel has to take a sample from the source image in the right proportion- I imagine this is how white pixel bleed can be simulated too.

Image compression is going well- I can get the girl's face from 1352 to 869 bytes with a hand-rolled version of LZ77. Decompression will be super easy as there is no fancy bit bashing or multiplication needed.

Still not enough IMO as I want to have an image at every location in the game. I am thinking of some strategies to improve it, given that it doesn't need to be entirely lossless...

[djangojames]

Finally, some 6502. I spent far too long fiddling with the compression algorithm but I finally came up with something that works. Now I can put images in the top right corner of the screen.

6502.org wrote:

Image no longer available: https://github.com/djangojames/exploratory/blob/master/blog/odysseus.png?raw=true

The compression algorithm is super simple. Any pattern longer than three bytes is indicated by a special byte, the LFB. Following the LFB is a byte which contains the length of the pattern in the hi-nybble and the offset to the pattern in the lo-nybble. The LFB is chosen as the least frequent byte in the source image. If it is seen, it is replaced with a zero. Look away now if you disapprove of this kind of hack Because images are spatially coherent, a special value for offset of "0" is used to indicate a match on the scanline directly above. In the initial version of the decompressor, matches are not allowed to go over a scanline. This severely degrades the performance- I can improve this later if I find that I am running out of memory to fit all the images in.

Code: Select all

 ;+ DECOMPRESS
             ;Expect the height in A
  DECOMPRESS 09E6 850A    STA $0A
             09E8 A000    LDY #$00
             09EA B100    LDA ($00),Y
             09EC 8508    STA $08
             09EE E600    INC $00            ;SRC
             09F0 D002    BNE $09F4          ;COPY-ROW
             09F2 E601    INC $01            ;SRC + 1
    COPY-ROW 09F4 A200    LDX #$00
             09F6 A000    LDY #$00
             09F8 A50C    LDA $0C
             09FA 8509    STA $09
             09FC A90D    LDA #$0D
   COPY-BYTE 09FE A100    LDA ($00,X)        ;X should be zero
             0A00 E600    INC $00            ;SRC
             0A02 D002    BNE $0A06
             0A04 E601    INC $01            ;SRC + 1
             0A06 C508    CMP $08
             0A08 F019    BEQ $0A23          ;PATTERN
             0A0A 9102    STA ($02),Y
             0A0C C8      INY
             0A0D C609    DEC $09
             0A0F D0ED    BNE $09FE          ;COPY-BYTE
     ROW-END 0A11 18      CLC
             0A12 A502    LDA $02            ;DEST
             0A14 6928    ADC #$28
             0A16 8502    STA $02            ;DEST
             0A18 A503    LDA $03            ;DEST + 1
             0A1A 6900    ADC #$00
             0A1C 8503    STA $03            ;DEST + 1
             0A1E C60A    DEC $0A
             0A20 D0D2    BNE $09F4          ;COPY-ROW
             0A22 60      RTS
     PATTERN 0A23 A100    LDA ($00,X)        ;X should be zero
             ;Get the pattern offset from the lo-nybble
             0A25 290F    AND #$0F
             0A27 D003    BNE $0A2C          ;SAME-ROW
             ;Pattern is on the row above
             0A29 18      CLC
             0A2A 6928    ADC #$28
    SAME-ROW 0A2C 850B    STA $0B
             0A2E A502    LDA $02            ;DEST
             0A30 38      SEC
             0A31 E50B    SBC $0B
             0A33 8504    STA $04            ;PREV
             0A35 A503    LDA $03            ;DEST + 1
             0A37 E900    SBC #$00
             0A39 8505    STA $05            ;PREV + 1
             ;Get the length from high nybble
             0A3B A100    LDA ($00,X)
             0A3D 4A      LSR
             0A3E 4A      LSR
             0A3F 4A      LSR
             0A40 4A      LSR
             0A41 18      CLC
             0A42 6903    ADC #$03
             0A44 AA      TAX
             ;Advance past the match byte
             0A45 E600    INC $00            ;SRC
             0A47 D002    BNE $0A4B          ;PATTERN-NEXT
             0A49 E601    INC $01            ;SRC + 1
             ;Now we have offset in PREV and length in X
PATTERN-NEXT 0A4B B104    LDA ($04),Y
             0A4D 9102    STA ($02),Y
             0A4F C8      INY
             0A50 C609    DEC $09
             0A52 F0BD    BEQ $0A11          ;ROW-END ;End of pattern and row
             0A54 CA      DEX
             0A55 F0A7    BEQ $09FE          ;COPY-BYTE ;End of pattern
             0A57 D0F2    BNE $0A4B          ;PATTERN-NEXT
             ;- DECOMPRESS
         ODD 0A59 09      /home/dan/Downloads/odd.bmp pixels (1166)
         ODD 0EE7 00      /home/dan/Downloads/odd.bmp colours (162)

[whartung]

What factor of compression are you seeing?

[djangojames]

Some example sizes for images,

Code: Select all

           
               Original Simple Best

cellardoor     1352     1073    995    26%
porsche        1352     1182   1042    23%
maxine         1352     1054    762    44%

I've implemented the simple scheme, but am working on the extension to make it a bit better. This involves removing some of the constraints in the LISP compressor, but leads to more complex code in the 6502 decompressor to handle scan-line spanning. Additionally there are 169 bytes of colour data and that does not compress at all well. (Like typically 20/30 bytes saving). There is probably a better scheme to be had there.

There's more detail and the original images at the blog here https://github.com/djangojames/explorat ... abbit-hole