https://wiki.stunts.hu/api.php?action=feedcontributions&feedformat=atom&user=DstienStunts Wiki - User contributions [en-us]2026-04-21T09:05:10ZUser contributionsMediaWiki 1.43.3https://wiki.stunts.hu/index.php?title=Debug_symbols&diff=7042Debug symbols2026-03-06T07:04:22Z<p>Dstien: FM Towns builds debug symbols.</p>
<hr />
<div>'''Debug symbols''' are fragments of a program's original source code used to annotate the binary produced by a compiler in order to provide context to otherwise hard-to-read disassembled machine code. Since it provides intimate details of a program's inner workings it is usually stripped from the release version of proprietary software.<br />
<br />
==FM Towns==<br />
The [[Game_versions#FM_Towns_version|FM Towns and FM Towns Marty]] builds of 4D Driving were shipped with debug symbols embedded in the ''[https://en.wikipedia.org/wiki/Phar_Lap_Software Phar Lap 386|DOS-Extender]'' payloads. Since the symbols and the executable code are stored in the same file this was most likely a mistake that went unnoticed. It also went unnoticed by the Stunts community until 2025. These symbols are a simple list of names for functions and global variables and the corresponding addresses, and they can therefore easily be converted to formats used by other debugging tools.<br />
<br />
This is the structure of the <tt>SYM1</tt> chunk found in Phar Lap's <tt>.EXP</tt> files:<br />
<br />
struct SEGMENT {<br />
uint8 name_length<br />
char name[name_length]<br />
uint32 unknown0<br />
uint32 unknown1<br />
uint32 selector <br />
}<br />
<br />
struct SYMBOL {<br />
uint8 name_length<br />
char name[name_length]<br />
uint32 address<br />
uint16 unk == 1<br />
}<br />
<br />
char magic[4] == "SYM1"<br />
uint16 unknown0 == 14<br />
uint32 unknown1 == 44<br />
uint32 sym_data_length<br />
<br />
SEGMENT segments[2]<br />
<br />
SYMBOL syms[...] // Until end-of-chunk<br />
<br />
===All found symbols===<br />
{| class="wikitable mw-collapsible mw-collapsed" data-expandtext="Show full list" data-collapsetext="Hide list" style="width:100%"<br />
! colspan="2" | Extracted debug symbols<br />
|-<br />
! FM Towns<br>4DDFMT.EXT (1993-02-16)<br />
! FM Towns Marty<br>4DDFMTM.EXP (1993-06-11)<br />
|-<br />
| style="vertical-align:top; width:50%;" |<br />
01a19c: ADD_OBJECT_TO_BUFFER<br />
03b83c: BARR_LIST<br />
03b3f0: BLTR_LIST<br />
038d78: BOTButcol<br />
03b36c: BSTR_LIST<br />
038d30: Blue<br />
038d3a: Brown<br />
038d82: CBlue<br />
03afc0: CHI1_LIST<br />
03b094: CHI2_LIST<br />
038d84: CRed<br />
016f9c: ConfirmMessage<br />
038d66: CredArtCol<br />
038d68: CredArtCols<br />
038d5a: CredCreCol<br />
038d5c: CredCreCols<br />
038d5e: CredDesCol<br />
038d60: CredDesCols<br />
038d6a: CredMusCol<br />
038d6c: CredMusCols<br />
038d62: CredProCol<br />
038d64: CredProCols<br />
038d56: CredTxtCol<br />
038d58: CredTxtCols<br />
038d50: Cursorcol1<br />
038d52: Cursorcol2<br />
038d34: Cyan<br />
01b6ac: DRAW_OBJECTS<br />
03dce0: DSK_filename<br />
038d3e: Darkgrey<br />
016fec: DriveAorB<br />
022c98: DriveRetry<br />
045874: Dso<br />
046948: Dtrackmatrix<br />
038d86: EBoxcol<br />
051378: EGBWork<br />
03831c: EGB_displayPage<br />
0382b8: EGB_displayStart<br />
038258: EGB_init<br />
038288: EGB_resolution<br />
0382f0: EGB_writePage<br />
03df46: ErrorCS<br />
03df48: ErrorIP<br />
038d54: Evalcol2<br />
03b398: FLBSTR_LIST<br />
03adc0: FLTRR_LIST<br />
03acec: FLTR_LIST<br />
038800: FMC_popclient<br />
0387e0: FMC_pushclient<br />
022390: FMTFREEMEMORY<br />
0223b8: FMTPURGEMEMORY<br />
0482b0: FMT_cheading<br />
03a7e0: FMT_index<br />
0482a4: FMT_inpoint<br />
020928: FMT_loadshape<br />
02097c: FMT_loadshapez<br />
0482ac: FMT_outplace<br />
048294: FMT_point<br />
04829c: FMT_point2<br />
019db8: FMT_printpoly<br />
0482b4: FMT_render2_matrix<br />
0209d0: FMT_scalecfxy<br />
03b3c4: FRBSTR_LIST<br />
03882c: FRB_getclient<br />
038848: FRB_popclient<br />
038818: FRB_setclient<br />
03abc8: FSTRI_LIST<br />
03abf4: FSTRL_LIST<br />
03ac2c: FSTRR_LIST<br />
03aaf8: FSTR_LIST<br />
03aca8: FTURR_LIST<br />
03ac64: FTUR_LIST<br />
03df4e: FontColor<br />
03df50: FontColor2<br />
03df4c: FontHeight<br />
03df52: FontStyle<br />
03df4a: FontWidth<br />
045890: FullName<br />
03b78c: GHWY1_LIST<br />
03b7b8: GHWY2_LIST<br />
038d32: Green<br />
03aeec: HLTR_LIST<br />
03b874: HPIPE_LIST<br />
03aec0: HSTRI_LIST<br />
03ae94: HSTR_LIST<br />
03b7e4: HWY1_LIST<br />
03b810: HWY2_LIST<br />
047a3e: HighIndex<br />
01a0b0: INIT_BUFFERS<br />
01a028: INIT_MATRIX<br />
01a0d8: INIT_OBJECTS_BUFFER<br />
01a080: INIT_PALETTE<br />
022290: InitRamDrive<br />
038768: KYB_clic<br />
038774: KYB_clrbuf<br />
038748: KYB_init<br />
03877c: KYB_inpchk<br />
0387b8: KYB_matrix<br />
03879c: KYB_read<br />
038750: KYB_setbuf<br />
03875c: KYB_setcode<br />
03e144: KanjiFont<br />
03df54: KanjiShape<br />
038b7c: KimG_getclient<br />
038b98: KimG_popclient<br />
038b68: KimG_setclient<br />
03b4c4: LCOR_LIST<br />
03b194: LOOP_LIST<br />
038d40: Lightblue<br />
038d44: Lightcyan<br />
038d42: Lightgreen<br />
038d3c: Lightgrey<br />
038d48: Lightmagenta<br />
038d46: Lightred<br />
038d88: MBoxcol<br />
038d7a: MIDButcol<br />
0502ec: MOSWork<br />
038634: MOS_disp<br />
03851c: MOS_end<br />
0386c4: MOS_horizon<br />
03865c: MOS_rdpos<br />
038724: MOS_resolution<br />
038694: MOS_setpos<br />
038390: MOS_start<br />
0386f4: MOS_vertical<br />
038d38: Magenta<br />
03a7e4: NP<br />
047a30: NewSI<br />
038d7c: OptColor<br />
03ab9c: PIPE_LIST<br />
03a7f4: PT<br />
0482c8: P_firstiplc<br />
0482cc: P_insertlen<br />
0482ca: P_iplc<br />
0482d0: P_listend<br />
0482c6: P_numpoints<br />
0482ce: P_pindex<br />
047a10: PlayerName<br />
04fc78: RAM_file<br />
03dcf0: RAM_filename<br />
03dcd8: RAM_filesize<br />
04fc88: RAM_saved<br />
038d7e: RBBoxcol<br />
038d80: RBCursorcol<br />
03b628: RCOR_LIST<br />
039a80: RPath<br />
0137b4: RayNullFunction<br />
038d36: Red<br />
039ad4: ReplayName<br />
038d8c: SDPAL_mcgacol1<br />
039098: SDPAL_mcgacol2<br />
038f94: SDPAL_mcgadither<br />
038e90: SDPAL_mcgatype<br />
051b98: SNDWork<br />
033d74: SND_driver<br />
033e04: SND_elevol_all_mute<br />
033df4: SND_elevol_mute<br />
033ddc: SND_elevol_set<br />
034028: SND_end<br />
033e28: SND_fm_timer_a_set<br />
033f20: SND_init<br />
033d18: SND_inst_change<br />
033db0: SND_inst_write<br />
033ed4: SND_int_timer_a_get<br />
033e90: SND_int_timer_a_set<br />
033ce4: SND_joy_in_1<br />
033d54: SND_key_abort<br />
033d00: SND_key_on<br />
033e14: SND_pan_set<br />
034140: SND_pcm_bank_load<br />
033e3c: SND_pcm_mode_set<br />
033e4c: SND_pcm_play<br />
033e6c: SND_pcm_play_stop<br />
033d64: SND_pcm_sound_delete<br />
033dcc: SND_pcm_sound_set<br />
033e7c: SND_pcm_status<br />
033d2c: SND_pitch_change<br />
033d40: SND_volume_change<br />
03ab70: SPIPE_LIST<br />
055b98: SaveTimer<br />
047a2c: Scores<br />
00f12c: ShowTitle<br />
00f1f8: ShowTitle2<br />
051978: SystemMemory<br />
043acc: TBIOSSTK_bottom<br />
038d76: TOPButcol<br />
039a2c: TPath<br />
03ab50: TUN_LIST<br />
039ae0: TerName<br />
038d6e: TrackBoxCol1<br />
038d70: TrackBoxCol2<br />
038d72: TrackBoxCol3<br />
038d74: TrackCursorCol<br />
03b168: USTR_LIST<br />
03b2bc: VCORK_LIST<br />
016f38: WarningMessage<br />
038d4c: White<br />
03ab24: XFSTR_LIST<br />
038d4a: Yellow<br />
016ee8: YesOrNoMessage<br />
042f14: __onexit_termination<br />
042c20: _base<br />
042e68: _bufsiz<br />
042af4: _ctype<br />
034ad4: _dos_findfirst<br />
034b04: _dos_findnext<br />
032418: _dos_getdiskfree<br />
042fd4: _doserr<br />
0430d4: _doserrno<br />
044ed8: _edata<br />
055d10: _end<br />
034d88: _exit<br />
032854: _fdopen<br />
042f04: _fmode<br />
042ecc: _fopen_max<br />
038d20: _fsoftonly<br />
032870: _fsopen<br />
042c28: _gda<br />
043468: _heapptr<br />
042c74: _iob<br />
034d9c: _itoa<br />
042c49: _mw1167<br />
038d20: _mw1167required<br />
038d20: _mw1167used<br />
038d20: _mw3167used<br />
042c47: _mw387<br />
038d20: _mw387used<br />
042c43: _mw8087<br />
038d20: _mw87only<br />
038d20: _mw87required<br />
038d20: _mw87used<br />
042c14: _mwCPU<br />
0328f0: _mwINIT<br />
042c15: _mwOS<br />
0378a8: _mw_87_f2add<br />
0378d2: _mw_87_f2compare<br />
0378cb: _mw_87_f2div<br />
0378c4: _mw_87_f2mpy<br />
037996: _mw_87_fbld<br />
03798c: _mw_87_fbstp<br />
0378e8: _mw_87_fflt<br />
037928: _mw_87_flload<br />
03790e: _mw_87_fload<br />
037915: _mw_87_flret<br />
037942: _mw_87_fpop<br />
037901: _mw_87_fret<br />
037939: _mw_87_ftload<br />
03792f: _mw_87_ftret<br />
037983: _mw_87_fxam<br />
037978: _mw_87_round<br />
03795c: _mw_87_trunc<br />
0378ef: _mw_87_ufflt<br />
033474: _mw_errnoset<br />
0381e4: _mwabort<br />
037b60: _mwaddmany<br />
036094: _mwaprintf<br />
042c38: _mwarglen<br />
042c2c: _mwargp<br />
038d20: _mwargregs<br />
038d20: _mwargstack<br />
042c32: _mwargvp<br />
0371dc: _mwbcd_to_real<br />
033240: _mwc_create<br />
033220: _mwc_dos_name<br />
033268: _mwc_open<br />
033298: _mwc_unlink<br />
0334c4: _mwcall_onexit_fcns<br />
033b78: _mwcalldos<br />
0321bc: _mwcfclose_all<br />
032f4c: _mwcfinit<br />
032f94: _mwcfterm<br />
033b58: _mwcheck_heap_integrity<br />
033450: _mwcmp<br />
0381b4: _mwdisplay<br />
033130: _mwdos<br />
0331e8: _mwdos_exit<br />
037ca1: _mwdshl<br />
033c5c: _mwdump_heap<br />
0335c4: _mweach_allocated_item<br />
033550: _mweach_free_item<br />
0334f8: _mweach_item<br />
042c4b: _mwemc87<br />
0332ac: _mwend<br />
042c54: _mwenv<br />
043460: _mwenvip<br />
042c3c: _mwenvp<br />
042c16: _mwes<br />
032ecb: _mwexpand_heap<br />
0374b8: _mwfabs<br />
0371f4: _mwfadd<br />
037e40: _mwfbld<br />
037f38: _mwfbstp<br />
03783c: _mwfcmp<br />
037824: _mwfcompare<br />
037788: _mwfcomparend<br />
037638: _mwfdiv<br />
03762c: _mwfdivr<br />
0374d8: _mwfdup<br />
033c08: _mwferr<br />
0333c4: _mwfileclass<br />
033114: _mwfinit<br />
037348: _mwflload<br />
03730c: _mwfload<br />
038d20: _mwfltused<br />
0374f4: _mwfmpy<br />
03745c: _mwfneg<br />
037cf0: _mwfpop<br />
037cb4: _mwfpstackoflo<br />
033a9e: _mwfree<br />
03748c: _mwfsub<br />
037480: _mwfsubr<br />
033114: _mwfterm<br />
037384: _mwftload<br />
0373e4: _mwftret<br />
035444: _mwfwrite_<br />
037d80: _mwfxam<br />
037424: _mwfxch<br />
0371a0: _mwget_exponent<br />
0324c0: _mwget_file_handle_and_info<br />
032f34: _mwgetds<br />
034d38: _mwgetenv2<br />
04345c: _mwgetenvbufnum<br />
0332ec: _mwhalt<br />
042c5a: _mwheap_expansion_enabled<br />
032eac: _mwheaphi<br />
032ea0: _mwheaplo<br />
033a00: _mwhmalloc<br />
037cd4: _mwinc_tos<br />
0357e8: _mwinit_buf<br />
042c10: _mwinput<br />
03368c: _mwinsert_into_free_chain<br />
042c42: _mwis_286<br />
033cbc: _mwkbnewline<br />
033ca0: _mwkbputs<br />
038d20: _mwldouble10<br />
0337c4: _mwleast_free_memory<br />
0331a4: _mwload_ds_dx<br />
033170: _mwload_ptr<br />
038d2c: _mwloc<br />
03340c: _mwlseek<br />
0379a0: _mwltox<br />
033a64: _mwmalloc<br />
0338e8: _mwmalloc2<br />
037bde: _mwnegmany<br />
043464: _mwnextenv<br />
037cf8: _mwnormalize<br />
036768: _mwout_convert_dreal<br />
036e94: _mwout_convert_real<br />
042c12: _mwoutput<br />
035918: _mwpad_to_field_width<br />
042c4e: _mwprognamep<br />
0371c4: _mwreal_to_bcd<br />
032901: _mwrestore_interrupts<br />
037a98: _mwrtox<br />
0358d0: _mwsend_pad<br />
03787e: _mwset_flags_after_compare<br />
0326c4: _mwset_flags_etc<br />
03785c: _mwset_rounding_proc<br />
032f2e: _mwset_stack_limits<br />
033018: _mwset_up_args<br />
0370e0: _mwspecial_number_msg<br />
032f31: _mwss<br />
042bfc: _mwstack_limit<br />
03822c: _mwstack_overflow<br />
033c8c: _mwstackdump<br />
038220: _mwstkerr<br />
037b89: _mwsubmany112<br />
037bb2: _mwsubmany121<br />
037060: _mwten_to_the_power<br />
04325c: _mwtmp_env_buf<br />
0332d4: _mwvsretcode<br />
03811c: _mwxdiv<br />
0380d0: _mwxmpy<br />
037c03: _mwxnormalize<br />
037c38: _mwxshl<br />
037c48: _mwxshr<br />
037c54: _mwxshrcnt<br />
037a15: _mwxtol<br />
037afd: _mwxtor<br />
0331c8: _mwzclose<br />
033338: _mwzread<br />
0333b0: _mwztrunc<br />
033364: _mwzwrite<br />
042c04: _osmajor<br />
042c05: _osminor<br />
042c04: _osversion<br />
042c16: _psp<br />
034e14: _strcmpi<br />
034e14: _stricmp<br />
038bb4: _strnicmp<br />
038cb0: _strrev<br />
042ed0: _temp_file_chain<br />
042c1c: _top<br />
041809: _zclipvalue<br />
03a0b0: abbrname<br />
03a569: abortbox<br />
023cbc: abortmessage<br />
021538: accelerate<br />
040034: activeflag<br />
04181c: adderr<br />
024e34: addexit<br />
03e200: addexiterr<br />
011cd4: addhighs<br />
02f9b4: addtimer<br />
020e38: addtotextbuf<br />
01bcc4: addzone<br />
023d28: adrtoseg<br />
047a78: allcarobject1<br />
047b78: allcarobject2<br />
02291c: allexist<br />
047b90: alloppresfile<br />
039b25: allowabort<br />
028cbb: andcf<br />
028ee2: andcfxy<br />
028f1a: andcfxya<br />
026ffa: andcline<br />
0284a4: andf<br />
02858b: andfxy<br />
0285c3: andfxya<br />
02769c: andline<br />
02a6a2: andpackcf<br />
02a900: andpackcfxy<br />
02a938: andpackcfxya<br />
0299ef: andpackf<br />
029abb: andpackfxy<br />
029af3: andpackfxya<br />
026ce5: andpixel<br />
026bf6: andpixelc<br />
027861: andrect<br />
027b7d: andrectc<br />
02157c: anim_car<br />
02181c: anim_champ<br />
0212fc: anim_finish<br />
011ff8: animateopponent<br />
00ee08: animcarsmk<br />
047bb6: animdelay<br />
00ea34: animhelmet1<br />
00ec90: animhelmet2<br />
047bae: animindex<br />
047bb4: animnum<br />
047bba: animx<br />
047bbc: animy<br />
0456ad: askfull<br />
033494: atexit<br />
000594: availmem<br />
047ba8: backfile<br />
025144: background<br />
019dbc: benprojectp<br />
0479fe: between<br />
03bc9c: bew11<br />
055bbc: biosticks<br />
04188c: biostickset<br />
047990: bitplanes<br />
03d7f4: blackpal<br />
03fea0: blknotfound<br />
046960: blocklistsign<br />
0205c4: blowengine<br />
03fe2c: bmem<br />
03bd00: bne22<br />
03bc88: bns11<br />
03bd14: bnw22<br />
0400a2: botfire<br />
00d378: boxcheck<br />
04798e: bpix<br />
0479eb: brakecolor<br />
03c10c: brew11<br />
03c0f8: brns11<br />
03bcd8: bse22<br />
03bcb0: bsn11<br />
03bcec: bsw22<br />
047b7c: buttfile<br />
03bcc4: bwe11<br />
00c760: calccoll<br />
0237cc: calcrpm<br />
039910: camerasizeinfo<br />
039b18: camheading<br />
039b16: camlen<br />
039b1f: cammode<br />
039b1a: campitch<br />
023d04: cap<br />
045604: car1<br />
047936: car1handle<br />
0477c4: car1ltires<br />
04786c: car1tcenter<br />
0477dc: car1toffsets<br />
047938: car2handle<br />
0477d0: car2ltires<br />
047908: car2tcenter<br />
047878: car2toffsets<br />
020778: carbubble<br />
02067c: carbump<br />
020620: carcrash<br />
04630c: cari<br />
046614: cari2<br />
020d68: carmovesfx<br />
04799c: carname<br />
048b00: carobjects1<br />
048b04: carobjects2<br />
039b38: carresname<br />
0206d0: carscrape<br />
020724: carsplash<br />
03dcb4: ccmsg<br />
0208f8: cdfade<br />
030844: cdfadeto<br />
030948: cdisbusy<br />
03dcac: cdmsg<br />
030928: cdpause<br />
030a78: cdplay<br />
030970: cdplaysection<br />
0389cc: cdr_cdinfo<br />
038a88: cdr_continue<br />
038ad4: cdr_exit1<br />
03894c: cdr_mphase<br />
038938: cdr_mstop<br />
0388d4: cdr_mtplay<br />
038a74: cdr_pause<br />
038b50: cdr_popclient<br />
038b30: cdr_pushclient<br />
038864: cdr_sdrvmd<br />
043b49: cdr_stat<br />
0388a0: cdr_status<br />
03086c: cdreadtoc<br />
030938: cdresume<br />
0208e4: cdsnddone<br />
03090c: cdstart<br />
030918: cdstop<br />
0307d8: cdupdatefade<br />
025c6c: centertext<br />
0413f5: centerx<br />
041401: centerxpix<br />
0413f7: centery<br />
041403: centerypix<br />
0413ed: cenxpix<br />
0413ef: cenypix<br />
047c2c: cfcount<br />
03dcb0: cfmsg<br />
03be04: ch1ew21<br />
03be18: ch1ns21<br />
03be2c: ch2ew21<br />
03bdf0: ch2ns21<br />
021ee0: champion<br />
02118c: change_palette<br />
00e2f4: changedrive<br />
00e3e0: checkcarname<br />
0171c4: checkdisk<br />
022a24: checkinstall<br />
025468: checkmodule<br />
01c260: checkobjtypes<br />
019ac4: checktracksyntax<br />
03db14: chmpname<br />
0259bc: chooseone<br />
042230: circles<br />
042234: circletbls<br />
04795c: cjoystate<br />
047c2e: clastcolor<br />
047999: clastx<br />
04799a: clastz<br />
01653c: clear_keyboardbuffer<br />
0000c4: clearinterpretsubs<br />
034530: clearscreen<br />
0245bc: clearwindow<br />
01356c: clearzone<br />
0248d0: clip<br />
04797a: clipby<br />
02e054: clipline<br />
024770: clippix<br />
024740: clippixwindow<br />
047978: clipty<br />
0248e0: clipwindow<br />
01bc2c: clipzone<br />
015e30: closeresource<br />
047976: cloudfudge<br />
0479fa: cmps<br />
03c15c: colew22<br />
03c120: colns22<br />
048a48: color1<br />
048a4c: color2<br />
04f678: colorbak<br />
04f978: colorcur<br />
048a54: colordither<br />
048a58: colorrnds<br />
048a50: colorstat<br />
03c148: colsn22<br />
03c134: colwe22<br />
01ed30: compiletrack<br />
025ec0: convertjoy<br />
03d7b8: coord1<br />
03d7c0: coord2<br />
01c1fc: copyobj<br />
01c214: copyobjtypes<br />
0227c0: copyq2a<br />
03c1ac: corew22<br />
03c170: corns22<br />
03c198: corsn22<br />
03c184: corwe22<br />
0479d4: countdown<br />
03dcb8: cpmsg<br />
019d60: cpycoord<br />
019d98: cpymatrix<br />
019d80: cpyscoord<br />
00445c: crack<br />
023db0: crcbyte<br />
00f2a0: credit1<br />
00f348: credit2<br />
030d8f: criterr<br />
04188a: critflag<br />
041884: critfunc<br />
030d26: crithandler<br />
030e27: ctrlc<br />
030e17: ctrlchandler<br />
03a558: curfname<br />
0475d8: curplane<br />
047a76: currcar<br />
03d7b0: currchannel<br />
03d7e2: currentbuf<br />
04016a: currentfont<br />
025e00: currentkeysub<br />
041894: currentwindow<br />
04b2e2: currpm<br />
051364: cursmask<br />
051360: cursshape<br />
0456c4: cusedash<br />
0479e5: cusereplay<br />
014fa8: cutpath<br />
045e90: cv<br />
0462f0: cvx<br />
044edc: cz<br />
047a02: czoneflag<br />
03dd02: datadrive<br />
04580c: dcar_matrix<br />
04796e: dclip<br />
039a28: deffont<br />
02009c: deinitenginesfx<br />
021114: delaykey<br />
02f9e8: deltimer<br />
0479cf: demomode<br />
0399d4: demoplane<br />
047920: demotime<br />
0479d0: didrace<br />
0210b0: disabletextbuf<br />
022670: diskaexist<br />
0224a0: diskexist<br />
022310: diskfile<br />
022524: diskfileerror<br />
0224e0: diskfileexist<br />
024e98: diskfree<br />
03a534: diskmsgs<br />
03a544: disknames<br />
03dd00: diskop<br />
022648: diskspace<br />
022fa0: disolve_entirememwindow<br />
022dcc: disolve_hiddenwindow<br />
022ea0: disolve_memwindow<br />
0257c0: displayall<br />
025768: displayone<br />
02458c: displayshapes<br />
024730: displaywindow<br />
02fbc4: ditheredpoly<br />
02fbd4: ditheredpolyf<br />
02fbe4: ditheredpolyi<br />
02fbf4: ditheredpolyip<br />
02fc04: ditheredpolyipt<br />
02fc14: ditheredpolyit<br />
02fc24: ditheredpolyp<br />
02fc34: ditheredpolypt<br />
02fc44: ditheredpolyt<br />
0208cc: docdplay<br />
0167e0: docursor<br />
0167c8: docursorinit<br />
006748: dodash<br />
00bcbc: doengine<br />
00c250: dohandling<br />
0162d4: dohidemouse<br />
0074a0: doreplay<br />
0267e0: dosexit<br />
00c8b8: doshock<br />
016328: doshowmouse<br />
015e98: doslider<br />
00ca14: dosteering<br />
014c28: draw3dboxin<br />
014b00: draw3dboxout<br />
014d54: draw3dbutton<br />
003a58: drawblimpworld<br />
02fb44: drawbox<br />
034360: drawcircle<br />
026de3: drawcline<br />
011950: drawhighs<br />
0030c0: drawhorizon<br />
002f04: drawhorizone<br />
02764b: drawline<br />
004e64: drawlogo<br />
0479d2: drawmode<br />
0135a0: drawmode4box<br />
011f78: drawopponent<br />
019398: drawpiecebox<br />
0345e0: drawpolyf<br />
02fd68: drawpolyp<br />
02fd54: drawpolypt<br />
02778f: drawrect<br />
027ad1: drawrectc<br />
0039f4: drawsort<br />
003f80: drawtext<br />
019514: drawtrackbox<br />
00082c: drawworld<br />
0005b0: drawworldflipzones<br />
024ea8: drive<br />
0169dc: drnd<br />
024e6c: dsiexit<br />
03dcbc: dsmsg<br />
0455b0: dtempzone<br />
023d30: dump<br />
025874: dumpone<br />
047964: ebufend<br />
047962: ebufstart<br />
047960: ebuftime<br />
02fa40: elapsedticks<br />
031ea0: ellipse<br />
031b4c: ellipseh<br />
0171f8: elticks<br />
0210bc: enabletextbuf<br />
039ba0: endgame<br />
039600: eng<br />
039640: eng2<br />
045940: enginebuffer<br />
020354: engineoff<br />
020280: engineon<br />
0208a4: enginesfxover<br />
020fc8: erasetext<br />
042eda: errno<br />
047bb8: et<br />
012084: evaluation<br />
034d70: exit<br />
03e1d8: exitsub<br />
03ff00: exmemerr<br />
03fed0: expanderr<br />
04558c: explbmapsdiam<br />
03dd34: ext<br />
051a7c: extkeysubs<br />
048a5c: facedir<br />
022fb4: fade_display<br />
023084: fade_displays<br />
032118: fclose<br />
04b2dc: fcolor<br />
04b2de: fcolor2<br />
03b938: few11<br />
032040: fflush<br />
034790: fgetc<br />
024960: filename<br />
03e1cc: filerrtxt<br />
024e04: fileselector<br />
024ce0: filesize<br />
024d00: filesizea<br />
024cf0: filesizez<br />
00ba20: findcar<br />
024e14: findfile<br />
024998: findfirst<br />
0249c0: findnext<br />
00d92c: finishgame<br />
016884: finishsong<br />
047bac: firstone<br />
0479e2: firsttime<br />
030e50: fixedmult<br />
03bc74: flbew11<br />
03bc60: flbns11<br />
03bc38: flbsn11<br />
03bc4c: flbwe11<br />
015014: floadreq<br />
017200: fluffyload<br />
02cec2: fmtandcf<br />
02d0cc: fmtandcfxy<br />
02d0f5: fmtandcfxya<br />
02c8aa: fmtandf<br />
02c967: fmtandfxy<br />
02c990: fmtandfxya<br />
031248: fmtandpackcf<br />
031288: fmtandpackcfxy<br />
0312c8: fmtandpackcfxya<br />
02d8f2: fmtandpackf<br />
02d9c0: fmtandpackfxy<br />
02d9e9: fmtandpackfxya<br />
0315d2: fmtandrect<br />
031975: fmtandrectc<br />
03455f: fmtclearscreen<br />
0311f8: fmtdisolvefast<br />
031208: fmtdisolvefastxya<br />
031218: fmtdisolveslow<br />
031228: fmtdisolveslowxya<br />
0314dc: fmtdrawrect<br />
0318d8: fmtdrawrectc<br />
0250f4: fmtenlargescreen<br />
03e1a4: fmtexten<br />
026b20: fmtgetpalette<br />
034590: fmthtclear<br />
024fd8: fmtinitgraphics<br />
02cc8e: fmtmovcf<br />
02ce78: fmtmovcfxy<br />
02cea1: fmtmovcfxya<br />
02c7bb: fmtmovf<br />
02c860: fmtmovfxy<br />
02c889: fmtmovfxya<br />
031238: fmtmovpackcf<br />
031278: fmtmovpackcfxy<br />
0312b8: fmtmovpackcfxya<br />
02d7e6: fmtmovpackf<br />
02d8a8: fmtmovpackfxy<br />
02d8d1: fmtmovpackfxya<br />
02d116: fmtorcf<br />
02d320: fmtorcfxy<br />
02d349: fmtorcfxya<br />
02c9b1: fmtorf<br />
02ca6e: fmtorfxy<br />
02ca97: fmtorfxya<br />
031258: fmtorpackcf<br />
031298: fmtorpackcfxy<br />
0312d8: fmtorpackcfxya<br />
02da0a: fmtorpackf<br />
02dad8: fmtorpackfxy<br />
02db01: fmtorpackfxya<br />
0316d4: fmtorrect<br />
031a12: fmtorrectc<br />
026ac9: fmtpalette<br />
026b60: fmtpaltocol<br />
02df77: fmtreadf<br />
02dfeb: fmtreadfxy<br />
02e011: fmtreadfxya<br />
0312f8: fmtscalecf<br />
031308: fmtscalecfxy<br />
031318: fmtscalecfxya<br />
031328: fmtscalef<br />
031338: fmtscalefxy<br />
031348: fmtscalefxya<br />
0313f8: fmtscalereccf<br />
031408: fmtscalereccfxy<br />
031418: fmtscalereccfxya<br />
0313c8: fmtscalerecf<br />
0313d8: fmtscalerecfxy<br />
0313e8: fmtscalerecfxya<br />
024ff4: fmtscreenmode<br />
031358: fmtsetcolortranslate<br />
031161: fmtsetscreen<br />
027ff4: fmtspeed<br />
02d5be: fmttmaskcf<br />
02d79c: fmttmaskcfxy<br />
02d7c5: fmttmaskcfxya<br />
02cbbf: fmttmaskf<br />
02cc44: fmttmaskfxy<br />
02cc6d: fmttmaskfxya<br />
031368: fmttmaskhpackcf<br />
031378: fmttmaskhpackcfxy<br />
031388: fmttmaskhpackcfxya<br />
02ddcc: fmttmaskhpackf<br />
02df2a: fmttmaskhpackfxy<br />
02df56: fmttmaskhpackfxya<br />
031398: fmttmaskpackcf<br />
0313a8: fmttmaskpackcfxy<br />
0313b8: fmttmaskpackcfxya<br />
02dc3a: fmttmaskpackf<br />
02dd82: fmttmaskpackfxy<br />
02ddab: fmttmaskpackfxya<br />
03e1c8: fmtwindotxt<br />
0247e4: fmtwindowdef<br />
02d36a: fmtxorcf<br />
02d574: fmtxorcfxy<br />
02d59d: fmtxorcfxya<br />
02cab8: fmtxorf<br />
02cb75: fmtxorfxy<br />
02cb9e: fmtxorfxya<br />
031268: fmtxorpackcf<br />
0312a8: fmtxorpackcfxy<br />
0312e8: fmtxorpackcfxya<br />
02db22: fmtxorpackf<br />
02dbf0: fmtxorpackfxy<br />
02dc19: fmtxorpackfxya<br />
0317d6: fmtxorrect<br />
031aaf: fmtxorrectc<br />
03b9c0: fne11<br />
03ba10: fne22<br />
03b924: fns11<br />
03b9d4: fnw11<br />
03ba24: fnw22<br />
024a04: fo<br />
04795e: fontheight<br />
039b14: fontwidest<br />
032838: fopen<br />
02813b: fortext<br />
028117: fortextxy<br />
034a30: fprintf<br />
03bc24: frbew11<br />
03bc10: frbns11<br />
03bbe8: frbsn11<br />
03bbfc: frbwe11<br />
0353b4: fread<br />
032fd8: free<br />
010b98: freealloppres<br />
004658: freeallscene<br />
010c58: freeallselopp<br />
03fe20: freebotidx<br />
025470: freememory<br />
025464: freepack<br />
03fe24: freetopidx<br />
025480: freetotop<br />
0267c0: frenchjoycal<br />
022cac: fromram<br />
01b65c: front_facing<br />
03bbd4: fruew11<br />
03bbac: fruns11<br />
03bb98: frusn11<br />
03bbc0: fruwe11<br />
0158a0: fsavereq<br />
0479de: fscrn<br />
03b998: fse11<br />
03b9e8: fse22<br />
0347f4: fseek<br />
04b2e0: fstyle<br />
03b9ac: fsw11<br />
03b9fc: fsw22<br />
0348d8: ftell<br />
047992: fts<br />
035730: fwrite<br />
0479d5: gabort<br />
005184: game<br />
005d78: gameint<br />
005d40: gameintinit<br />
048af8: gameobjects1<br />
048afc: gameobjects2<br />
03a5aa: gamepauseflag<br />
04584c: gameres<br />
011bc0: genhline<br />
0208c4: getanimcounter<br />
0310c0: getbiostick<br />
0347c0: getc<br />
0347d8: getchar<br />
022218: getcurrentpalette<br />
0229fc: getdrive<br />
022a74: getdriveacd<br />
022a9c: getdriveq<br />
027fef: getds<br />
034b2c: getenv<br />
0117cc: getmodelname<br />
023f60: getmousepos<br />
0256ec: getnum<br />
022078: getoppfilename<br />
01b610: getoutcode<br />
026a58: getpalette<br />
026a58: getpalettefar<br />
01c31c: getpinfo<br />
0133f4: getprotection<br />
0233d8: getpstring<br />
015e40: getres<br />
015e50: getresl<br />
00e0a8: getsimdata<br />
025cb4: getstring<br />
025cc4: getstringi<br />
02fa2c: gettick<br />
00d020: gettlistpoint<br />
01e0a0: getwpinfo<br />
03bb84: gew11<br />
03c0e4: ghyew11<br />
03c0bc: ghyns11<br />
03c0a8: ghysn11<br />
03c0d0: ghywe11<br />
03bb5c: gns11<br />
046990: go<br />
00b03c: gotosim<br />
045220: gpbmaps<br />
03e214: graphicmode<br />
039930: gravity<br />
0479d6: grip<br />
047980: ground<br />
0462f4: gs<br />
03bb48: gsn11<br />
03bb70: gwe11<br />
03947c: headingzones<br />
03ba4c: hew11<br />
0248f0: hiddenwindow<br />
023f14: hidemouse<br />
024ed8: hideprint<br />
047974: highestsceneryheight<br />
03fe30: highwater<br />
03e216: hirestext<br />
03bad0: hne22<br />
03ba38: hns11<br />
03bae4: hnw22<br />
025154: horizsync<br />
03bd8c: hpew11<br />
03bd78: hpns11<br />
03baa8: hse22<br />
03babc: hsw22<br />
025164: hsyncstate<br />
03ba84: huew11<br />
03ba60: huns11<br />
015dbc: hurrykey<br />
03c094: hyew11<br />
03c080: hyns11<br />
0392cc: hzoneEN<br />
039314: hzoneES<br />
039284: hzoneNE<br />
03923c: hzoneNW<br />
03935c: hzoneSE<br />
0393a4: hzoneSW<br />
039434: hzoneWN<br />
0393ec: hzoneWS<br />
02546c: ifmodule<br />
0456b8: inint<br />
01e62c: init_3dcars<br />
01e410: init_3dpieces<br />
00de48: init_explode<br />
047a74: initallcar<br />
00a9a4: initcar<br />
020d48: initcarmovesfx<br />
02f8f0: initctimer<br />
0007b0: initdrawworld<br />
02f8e0: initdtimer<br />
0200e8: initengine<br />
020044: initenginesfx<br />
024f98: initgraphics<br />
000078: initinterpretsubs<br />
025e68: initjoy<br />
025f44: initjoyl<br />
025f4c: initjoyr<br />
00d774: initlogo<br />
025224: initmemmax<br />
025204: initmemory<br />
025234: initmemsize<br />
0000f4: initmodes<br />
023e04: initmouse<br />
0073a4: initmousedrive<br />
01bb60: initnm<br />
024ee8: initprofile<br />
024ef8: initprofsect<br />
00468c: initscenery<br />
01352c: initselections<br />
00ab40: initsim<br />
030ac4: initsound<br />
025cf4: initstatekey<br />
02f948: initstimer<br />
024fa4: inittext<br />
02f8d0: inittimer<br />
005d10: initworld<br />
025e08: inkey<br />
02284c: installa<br />
02280c: installhigtrk<br />
0137b8: instringz<br />
0268f0: int3dhypot<br />
02ecae: intatan<br />
02ec98: intcos<br />
03b974: inte11<br />
026778: interpretclear<br />
0266b8: interpretkey<br />
026724: interpretsub<br />
02ed9a: inthypot<br />
0479e7: intraffic<br />
02ec10: intsin<br />
03e1d4: invalid<br />
0455b8: inwater<br />
03bd64: ipew11<br />
03bd50: ipns11<br />
033cd4: itoa<br />
02641c: joybuttons<br />
026640: joybuttonsb<br />
0267bc: joycal<br />
039b52: joycaled<br />
04003c: joycalib<br />
0267c4: joycall<br />
0267cc: joycallo<br />
0267d0: joycalo<br />
0267c8: joycalr<br />
0267d4: joycalro<br />
040040: joyclock<br />
026028: joycos<br />
0260ac: joycosb<br />
0260fc: joycosbi<br />
02605c: joycosi<br />
0400ae: joydown<br />
0400b2: joyleft<br />
0400b0: joyleftdown<br />
0400a4: joyleftup<br />
0267ac: joyoffl<br />
0267b4: joyoffr<br />
0267f0: joyon<br />
0400aa: joyright<br />
0400ac: joyrightdown<br />
0400a8: joyrightup<br />
026254: joystate<br />
026458: joystateb<br />
025e70: joystick<br />
025f54: joystickb<br />
0400a6: joyup<br />
025ed4: joyxpot<br />
025fb0: joyxpotl<br />
026020: joyxpotr<br />
025f0c: joyypot<br />
025fe8: joyypotl<br />
026024: joyypotr<br />
026150: kbdjoystate<br />
038a9c: kcdr_status<br />
026800: keybiosticks<br />
026810: keyon<br />
040038: keyprog<br />
025d24: keystate<br />
025df4: keysub<br />
03ff34: keysubs<br />
025e1c: keyticks<br />
025e3c: keywait<br />
026820: keywaitbios<br />
0479d1: lang<br />
0479e0: lastdash<br />
0479df: lastdrawmode<br />
0479e8: lastintraffic<br />
0479e9: lastrbox<br />
0479e4: lastreplay<br />
0479e6: lastrpause<br />
0479ec: lastscenery<br />
0400ca: lbotfire<br />
04797c: lclipby<br />
03dca8: ldmsg<br />
045850: ledfont<br />
01bb9c: lgabs<br />
051374: library<br />
020fb0: limity<br />
04222c: linefunct<br />
0400d6: ljoydown<br />
0400da: ljoyleft<br />
0400d8: ljoyleftdown<br />
0400cc: ljoyleftup<br />
0400d2: ljoyright<br />
0400d4: ljoyrightdown<br />
0400d0: ljoyrightup<br />
0400ce: ljoyup<br />
0220d4: loadalloppfile<br />
010b38: loadalloppres<br />
004618: loadallscene<br />
010be0: loadallselopp<br />
0242b0: loadandshapepack<br />
0242d0: loadandshapepacka<br />
0242c0: loadandshapepackz<br />
004844: loaddrawbits<br />
022d80: loaddrivefile<br />
022ce4: loaddrivefileatz<br />
022d34: loaddrivefilez<br />
024ad8: loadfile<br />
024af8: loadfilea<br />
0249dc: loadfileat<br />
024a50: loadfileata<br />
0249f0: loadfileatz<br />
024ae8: loadfilez<br />
0070f4: loadgamefiles<br />
0166dc: loading<br />
022090: loadoppfile<br />
024b44: loadpack<br />
024b64: loadpacka<br />
024ca8: loadpackat<br />
024cd0: loadpackata<br />
024cbc: loadpackatz<br />
024b54: loadpackz<br />
0003b8: loadpalandmouse<br />
022438: loadram<br />
00669c: loadreplay<br />
023fbc: loadshape<br />
023fdc: loadshapea<br />
023fcc: loadshapez<br />
00658c: loadtornamenttog<br />
047954: loady<br />
024080: locateshape<br />
0241bc: locateshapes<br />
0241f0: locateshapesz<br />
024124: locateshapez<br />
03fe18: lockbotidx<br />
0252c4: lockedmemory<br />
03fe1c: locktopidx<br />
03bfcc: loflen22<br />
03bf60: loflnw22<br />
03bfa8: loflse22<br />
03bf84: loflws22<br />
03c05c: lofres22<br />
03bff0: lofrne22<br />
03c038: lofrsw22<br />
03c014: lofrwn22<br />
004898: logo<br />
0455d4: logo1<br />
0455ec: logo2<br />
0455d0: logo_ticks<br />
04561c: logoclip<br />
047972: lowestsceneryheight<br />
03bd3c: lpew21<br />
03bd28: lpns21<br />
047968: lrndtime<br />
0400c8: ltopfire<br />
00e448: main<br />
005b50: mainkey<br />
039a24: mainres<br />
01e5f8: makecarname<br />
01b868: makematrix<br />
015824: makename<br />
019df0: makeobjdef<br />
016910: maketime<br />
01c0c4: makezonelist<br />
032ff4: malloc<br />
0456ae: maskdash<br />
0456b0: maskshapes<br />
051b88: matrix<br />
0418a6: maxx<br />
0418aa: maxy<br />
047b80: mboxfile<br />
047c0c: mboxzone<br />
0502e8: mbuttons<br />
042124: mcgacolorxlate<br />
0311a8: mcgatranslation<br />
0311cd: mcgatransrange<br />
045804: mch<br />
045806: mchit<br />
045808: mchithdg<br />
045800: mcp<br />
045802: mcr<br />
0457f4: mcx<br />
0457f8: mcy<br />
0457fc: mcz<br />
016e5c: mdosexit<br />
0171c8: memerr<br />
0256c4: memmovef<br />
0259ec: memsizedisplay<br />
045848: memwindow<br />
01bbac: mergezones<br />
013824: messagebox<br />
048ac0: mheading_matrix<br />
0418a4: minx<br />
0418a8: miny<br />
047a28: miscres<br />
045628: miscshapes<br />
04521c: miscshapes2<br />
016bd0: mjoycal<br />
016be0: mjoycalx<br />
016c3c: mkeyon<br />
000000: mloadmcgaz<br />
047b88: mm_but<br />
020b74: mm_drawbox<br />
020b14: mm_drawcursor<br />
020a58: mm_drawline<br />
020a80: mm_drawrect<br />
020aec: mm_drawrectc<br />
020bb0: mm_fortextxy<br />
020c30: mm_fshadowtext<br />
020bf0: mm_movtxy<br />
048ad4: mmatrix<br />
016ca0: mmouseon<br />
016d64: mmusictog<br />
016cfc: mnullfunc<br />
044ed8: mnumzones<br />
03e218: moddir<br />
021270: mode1off<br />
021218: mode1on<br />
03a268: modelname<br />
04f620: modematrix<br />
0005a0: modsize<br />
0254fc: modulesize<br />
023dc0: monocursor<br />
043ad4: mos_control_flg<br />
043ad0: mos_event_adr<br />
043ad8: moswork_adr<br />
043adc: moswork_seg<br />
039b22: mouseactive<br />
04795a: mouseb<br />
0164d8: mousecursor<br />
039b1c: mousedrive<br />
03e19c: mouseflag<br />
047944: mousemaskw<br />
0162b8: mouseoff<br />
016294: mouseon<br />
039b23: mouseonscreen<br />
039b21: mouseonstat<br />
047940: mouseshapew<br />
03e1a0: mouseshown<br />
0073e8: mousesteer<br />
04793c: mouseunderw<br />
047956: mousex<br />
047958: mousey<br />
028a4e: movcf<br />
028c53: movcfxy<br />
028c8b: movcfxya<br />
00dfac: move_explode<br />
00db94: move_on_plane<br />
008e30: movecar<br />
005f5c: moveeverything<br />
006308: movehelicopters<br />
00d924: movelogo<br />
00873c: moveopponent<br />
00b310: moveplayer<br />
00b100: movesim<br />
028372: movf<br />
025cd4: movftxy<br />
02843c: movfxy<br />
028474: movfxya<br />
0475c0: movp<br />
02a3e3: movpackcf<br />
02a63a: movpackcfxy<br />
02a672: movpackcfxya<br />
0298c2: movpackf<br />
029987: movpackfxy<br />
0299bf: movpackfxya<br />
02827a: movt<br />
028256: movtxy<br />
047c38: mpactive<br />
048aac: mpitch_matrix<br />
047c30: mpstat<br />
03a61c: mpush<br />
0171bc: mretryhandler<br />
048a98: mroll_matrix<br />
01703c: msetrender<br />
046940: msong<br />
016de0: msoundtog<br />
04562c: msteerx<br />
04566c: msteerxvalid<br />
016d00: msystempause<br />
039b1d: musicon<br />
026830: musictog<br />
04693c: mvoice<br />
0502e4: mx<br />
0502e6: my<br />
014f88: mycenter<br />
0168b8: myclearfont<br />
0456bc: myclipzone<br />
000074: myfinddone<br />
000010: myfindfirst<br />
00006c: myfindnext<br />
023839: mygetseeds<br />
016724: myitoa<br />
015ac0: mykey<br />
016658: mykeywait<br />
016a04: myload<br />
016ac4: myloadat<br />
01c22c: mymemcmp<br />
048b08: myobj<br />
023854: myrandom<br />
039b28: myseed<br />
016898: mysetfont<br />
02381e: mysetseeds<br />
00cb20: myupdatesfx<br />
00cfbc: myupdatesfx1<br />
00cf80: myupdatesfx2<br />
045054: mz<br />
0451bc: mzkey<br />
0159d4: namecopy<br />
022aec: namedrive<br />
03dcc8: ndmsg<br />
025320: negblockmove<br />
025dac: nextkey<br />
03dcd0: nlmsg<br />
0479fc: nmps<br />
03fe6c: noblkerr<br />
039b1e: nohandling<br />
03fe34: nomemerr<br />
03a554: noreadpacket<br />
01ba90: norm_zone<br />
025d64: normkey<br />
026090: normkeyi<br />
05197c: normkeysubs<br />
03e1c0: norowspc<br />
03e1d0: notpack<br />
04798c: npix<br />
03dcd4: nrmsg<br />
03dccc: nsmsg<br />
023da8: nullfunction<br />
023dac: nullprint<br />
03a8ac: nullzone<br />
038d4e: numcolors<br />
0267d8: numlockclear<br />
026840: numlockset<br />
04791c: numroadblocks<br />
047994: numtrkcameras<br />
047995: numtrksigns<br />
047a00: nzoneflag<br />
048b0c: objtype1<br />
049e94: objtype2<br />
03c1c0: objtypes<br />
03beac: oflen11<br />
03be40: oflnw11<br />
03be88: oflse11<br />
03be64: oflws11<br />
03bf3c: ofres11<br />
03bed0: ofrne11<br />
03bf18: ofrsw11<br />
03bef4: ofrwn11<br />
039a20: oldlist<br />
015dcc: openresource<br />
022110: oppanim<br />
04f65c: oppfile<br />
03dc88: oppfilename<br />
0479cc: oppinit<br />
039b30: oppname<br />
01fd50: opponentcompile<br />
04696c: opponentlist<br />
04692c: oppspeeds<br />
005f30: optimizejoystick<br />
005efc: optimizejoyxpot<br />
0114f8: options<br />
028f4a: orcf<br />
029171: orcfxy<br />
0291a9: orcfxya<br />
027215: orcline<br />
0285f3: orf<br />
0286da: orfxy<br />
028712: orfxya<br />
0276ed: orline<br />
02a968: orpackcf<br />
02abc6: orpackcfxy<br />
02abfe: orpackcfxya<br />
029b23: orpackf<br />
029bef: orpackfxy<br />
029c27: orpackfxya<br />
026d16: orpixel<br />
026c30: orpixelc<br />
027931: orrect<br />
027c29: orrectc<br />
02561c: packmemory<br />
041890: pagedwindow<br />
024900: pageflip<br />
03919c: palcol1<br />
0391a0: palcol2<br />
0391a8: paldither<br />
025174: palettecolor<br />
0391a4: palstat<br />
020a38: paltocol<br />
0479dc: passed<br />
051368: pauseflag<br />
030bf8: pausesound<br />
030c7c: pcmdone<br />
030c10: pcmstart<br />
030c6c: pcmstop<br />
00de0c: pdist<br />
047988: penalty<br />
04799b: penaltytime<br />
047993: pflip<br />
04f61c: pict<br />
04798a: pix<br />
0418b4: pixmaxx<br />
0418b2: pixminx<br />
00dd7c: plane_distance<br />
046924: planes<br />
016870: playsong<br />
041880: pm_ceoff<br />
041888: pm_cesel<br />
047922: pnum<br />
047924: pobjx<br />
047926: pobjy<br />
047928: pobjz<br />
039928: pointsizeinfo<br />
0436c8: polling_sub_int<br />
02fdb9: poly<br />
02fdbc: polycmn<br />
042226: polycolor2<br />
042228: polyfunct<br />
042224: polymask<br />
02fd8e: polyp<br />
01b518: polysort<br />
0252ac: poolmemory<br />
0252f4: posblockmove<br />
027dc4: print<br />
027f54: printattribute<br />
027f73: printbyte<br />
027f92: printbytexy<br />
027fb1: printchar<br />
027fd0: printcharxy<br />
027d81: printclear<br />
024eb8: printdivby0<br />
034a0c: printf<br />
027f35: printscroll<br />
023150: printsjis<br />
027f16: printxy<br />
024f08: profileoff<br />
024f18: profileon<br />
024f28: profsectoff<br />
024f38: profsecton<br />
02f53d: projectc<br />
02f162: projectorgp<br />
02f30a: projectp<br />
016b98: pullmouse<br />
0220f8: purgealloppfile<br />
025e14: purgekey<br />
025490: purgememory<br />
0220bc: purgeoppfile<br />
030a90: purgesound<br />
016b70: pushmouse<br />
0238db: putsjis<br />
025214: quitmemory<br />
023e8c: quitmouse<br />
03a556: r_bgcolor<br />
047a6e: raceresult<br />
032220: rand<br />
030758: random<br />
02fc54: randompoly<br />
02fc64: randompolyf<br />
02fc74: randompolyi<br />
02fc84: randompolyip<br />
02fc94: randompolyipt<br />
02fca4: randompolyit<br />
02fcb4: randompolyp<br />
02fcc4: randompolypt<br />
02fcd4: randompolyt<br />
0400b6: rbotfire<br />
02c6c3: readf<br />
02c743: readfxy<br />
02c77b: readfxya<br />
025184: readhiddenscreen<br />
01181c: readhighs<br />
023de0: readmonoatt<br />
023dd0: readmonochar<br />
023eb8: readmouse<br />
026d78: readpixel<br />
025194: readscreen<br />
0251a4: redshift<br />
01eae4: remove_3dcars<br />
01e5c4: remove_3dpieces<br />
004888: removedrawbits<br />
007338: removegamefiles<br />
005d60: removegameint<br />
004818: removescenery<br />
0246f8: removewindow<br />
048280: render_matrix<br />
039b24: renderlevel<br />
047bcc: replay_flag<br />
0475dc: replaybuff<br />
045624: replaybuflen<br />
0475e0: replayso<br />
025350: reservememory<br />
020e1c: resetalltextbuf<br />
030de0: resetcriterr<br />
024e94: resetdivby0<br />
024f48: resetprofile<br />
024f58: resetprofsect<br />
025d1c: resetstatekey<br />
020df4: resettextbuf<br />
02fa54: resettick<br />
025544: resizememory<br />
000574: resmem<br />
01498c: restoreboxwindow<br />
025b78: restorefont<br />
020cd0: restorefont4<br />
02224c: restorepalette<br />
020f44: restoretext<br />
0210c8: restoretextbox<br />
020f00: restoretextgraphic<br />
021020: restoretextwindow<br />
02f9a0: restoretimer<br />
0247c8: restorewindow<br />
030c04: resumesound<br />
034944: rewind<br />
031450: ring<br />
0400c2: rjoydown<br />
0400c6: rjoyleft<br />
0400c4: rjoyleftdown<br />
0400b8: rjoyleftup<br />
0400be: rjoyright<br />
0400c0: rjoyrightdown<br />
0400bc: rjoyrightup<br />
0400ba: rjoyup<br />
04187c: rm_cevec<br />
04691c: rndseed<br />
04791a: rndtime<br />
046950: roadlistc<br />
046954: roadlistld<br />
046964: roadlistp1<br />
046968: roadlistp2<br />
046958: roadlistx<br />
04695c: roadlistz<br />
01ff48: roadupcheck<br />
0418a0: rowtbl<br />
0479d3: rpause<br />
0479f8: rpfxrate<br />
0479da: rspeed<br />
0400b4: rtopfire<br />
047620: rtzline<br />
03bb0c: ruew11<br />
03baf8: runs11<br />
03bb20: rusn11<br />
03bb34: ruwe11<br />
0300b1: s1linex<br />
02ffef: s1linexc<br />
03020b: s2linex<br />
022358: sameext<br />
039680: samplefile<br />
014898: saveboxwindow<br />
020f2c: savecurrenttextwindow<br />
022c08: savedrivefile<br />
022b78: savedrivefilez<br />
02f76c: savefile<br />
02f780: savefilez<br />
022680: savefloppy<br />
025b68: savefont<br />
020c9c: savefont4<br />
011ee8: savehighs<br />
017264: saveobject<br />
022234: savepalette<br />
024f68: saveprofile<br />
024f78: saveprofsect<br />
0223e0: saveram<br />
0228f4: saveramfiles<br />
0066fc: savereplay<br />
020ee8: savetextgraphic<br />
020ebc: savetextwindow<br />
020f08: savetextzone<br />
0247ac: savewindow<br />
02bf3f: scalecf<br />
02c0c8: scalecfxy<br />
02c0fd: scalecfxya<br />
02bdba: scalef<br />
02bee9: scalefxy<br />
02bf1e: scalefxya<br />
02c358: scalereccf<br />
02c646: scalereccfxy<br />
02c6a2: scalereccfxya<br />
02c11e: scalerecf<br />
02c2db: scalerecfxy<br />
02c337: scalerecfxya<br />
030cae: scalethicknessxp<br />
030cca: scalethicknessyp<br />
026850: scancode<br />
0479c4: scarname<br />
0455bc: scenefile<br />
039582: sceneloaded<br />
045598: scenery<br />
0455a8: sceneryh<br />
039b20: sceneryloaded<br />
045594: sceneshapes<br />
0418ac: scrbyts<br />
0251c4: screenorigin<br />
0251b4: screensnap<br />
0418b6: screenwindow<br />
051318: screenwindowsec<br />
05133c: screenwindowvga<br />
016694: screenwipe<br />
041894: scrfrm<br />
047914: scriptindex<br />
047916: scriptindexend<br />
0479dd: scrn<br />
047b84: scrnfile<br />
039a1c: scrnlist<br />
0251d4: scrolldown<br />
0251e4: scrollup<br />
041898: scrseg<br />
0418b0: scrxpixels<br />
051376: sectionnumber<br />
04184c: seed<br />
000348: seedrandom<br />
023d20: segtoadr<br />
00f588: select<br />
00fdac: selectcar<br />
010c94: selectopponent<br />
020de8: selecttextbuf<br />
047a40: selofile<br />
047a44: seloshapes<br />
0310d8: setbiosticks<br />
021174: setblackpal<br />
022264: setblacktext<br />
024e90: setdivby0<br />
025b88: setfont<br />
026860: setjoykeys<br />
026870: setjoykeysl<br />
026880: setjoykeysr<br />
023e94: setmousebounds<br />
023f38: setmousepos<br />
023e00: setmouseratio<br />
023f94: setmousex<br />
023fa8: setmousey<br />
030a8c: setmusicabort<br />
02f47a: setprojectc<br />
02f1c3: setprojectp<br />
02f1a1: setprojectpb<br />
02fce4: setrandompix<br />
02fa60: setticks<br />
01eb78: settires<br />
0267dc: settypeahead<br />
02f751: setzclip<br />
039920: sfpostsizeinfo<br />
047a08: sfxfile<br />
030b18: sfxoff<br />
030b38: sfxon<br />
0479ed: sfxstat<br />
0479ee: sfxstat1<br />
0479ef: sfxstat2<br />
030b58: sfxtoggle<br />
0237fd: sgn<br />
0165d8: shadowtext<br />
024224: shapecount<br />
024284: shapename<br />
024334: shapepack<br />
024230: shapepointer<br />
023be0: shellsort<br />
0251f4: shiftscreen<br />
023ef0: showmouse<br />
024f88: showprint<br />
03e1b8: shperrmsg<br />
039918: signsizeinfo<br />
00438c: sink<br />
03de40: sjistable<br />
043acc: skb_event_adr<br />
04797e: sky<br />
02e042: slopeline<br />
045854: smallfont<br />
0479db: smdelay<br />
03e1bc: snderrmsg<br />
045858: so<br />
0479d7: solid<br />
031428: solidellipseh<br />
030ec0: solidtire<br />
047a0c: songfile<br />
030b7c: songoff<br />
030ba4: songon<br />
030be8: songover<br />
030bcc: songtoggle<br />
01c19c: sortzonelist<br />
033d74: sound_bios<br />
033d98: sound_bios2<br />
026890: soundoff<br />
0268a0: soundon<br />
0268b0: soundtog<br />
047984: speedocol<br />
03bddc: spew11<br />
03bdb4: spns11<br />
034abc: sprintf<br />
03bda0: spsn11<br />
03bdc8: spwe11<br />
032248: srand<br />
02fa24: sseqds<br />
0479d9: staging<br />
0268c0: standardkeys<br />
04016e: standfont<br />
04791e: startblockhdg<br />
047996: startblockx<br />
047998: startblocky<br />
047997: startblockz<br />
020d04: startcarsfx<br />
0205a4: startengine<br />
0207cc: startskid<br />
020828: startskid2<br />
040060: statekey<br />
040080: statekeyb<br />
0456c8: status<br />
0479f4: steerval<br />
0205b4: stopengine<br />
020884: stopskid<br />
032318: strcat<br />
0323dc: strchr<br />
032254: strcpy<br />
015e80: strcpyfar<br />
033cdc: stricmp<br />
032380: strncmp<br />
032298: strncpy<br />
038248: strnicmp<br />
038250: strrev<br />
023df0: structshellsortup<br />
0400dc: suppressprint<br />
03dca4: svmsg<br />
047bd0: sw<br />
041874: swSFX<br />
041878: swSong<br />
039b26: swindowindex<br />
0211d8: switch_palette<br />
047bf0: swmemerror<br />
03dcc0: swmsg<br />
047bf4: swwindow<br />
0479f0: swwindowtbl<br />
019e90: symTransf<br />
0268d0: systempause<br />
044f54: sz<br />
044fcc: szalt<br />
045218: szheading<br />
047986: tcamlen<br />
04580a: tclipy<br />
0452d0: td<br />
0452d4: tdraw<br />
045294: tdrawindex<br />
045234: tdrawnum<br />
045238: tdrawobj<br />
045258: tdrawsvalue<br />
00f790: teditmain<br />
047bb0: tempshape<br />
0458f0: tempstring<br />
039b10: terheight<br />
04694c: terrain<br />
031114: testbiosticks<br />
025d5c: testkey<br />
02fa84: testticks<br />
04b2ec: textbuf<br />
040168: textchr<br />
028222: textchrxy<br />
025b34: textcolor<br />
03d7e4: textend<br />
025b94: textnpixels<br />
025c10: textpixels<br />
025b4c: textposition<br />
03d7e0: textwindowoff<br />
04b2e4: textzone<br />
03b960: tfew11<br />
03b94c: tfns11<br />
04774c: tfzs<br />
047788: tfzsh<br />
030c94: thickness<br />
030ce6: thicknessxp<br />
030d06: thicknessyp<br />
02fa34: tickcount<br />
055b9c: ticks<br />
055ba0: tickset<br />
055ba4: tickval<br />
0268e0: timedmessage<br />
02faa0: timedwait<br />
0436bc: timer_a_int<br />
0436c0: timer_b_int<br />
0436c4: timer_sub_int<br />
02f844: timerint<br />
02f888: timerintb<br />
030e68: tire<br />
047a70: titlefile<br />
047a24: titleptr<br />
00f3f0: titles<br />
029468: tmaskcf<br />
02963c: tmaskcfxy<br />
029674: tmaskcfxya<br />
028891: tmaskf<br />
02891b: tmaskfxy<br />
028953: tmaskfxya<br />
02b641: tmaskhpackcf<br />
02b99c: tmaskhpackcfxy<br />
02b9d7: tmaskhpackcfxya<br />
02a0a6: tmaskhpackf<br />
02a1e6: tmaskhpackfxy<br />
02a221: tmaskhpackfxya<br />
02aef4: tmaskpackcf<br />
02b23a: tmaskpackcfxy<br />
02b272: tmaskpackcfxya<br />
029d8b: tmaskpackf<br />
029ebd: tmaskpackfxy<br />
029ef5: tmaskpackfxya<br />
0296a4: tmaskxcf<br />
029878: tmaskxcfxy<br />
0298a1: tmaskxcfxya<br />
028983: tmaskxf<br />
028a04: tmaskxfxy<br />
028a2d: tmaskxfxya<br />
02ba07: tmaskxhpackcf<br />
02bd6d: tmaskxhpackcfxy<br />
02bd99: tmaskxhpackcfxya<br />
02a251: tmaskxhpackf<br />
02a396: tmaskxhpackfxy<br />
02a3c2: tmaskxhpackfxya<br />
02b2a2: tmaskxpackcf<br />
02b5f7: tmaskxpackcfxy<br />
02b620: tmaskxpackcfxya<br />
029f25: tmaskxpackf<br />
02a05c: tmaskxpackfxy<br />
02a085: tmaskxpackfxya<br />
03fe28: tmem<br />
055ba8: tmrsub<br />
022ac4: togdrive<br />
022b48: toobig<br />
0400a0: topfire<br />
039b40: tornamentflag<br />
00e198: tornamentload<br />
039b42: tornamentmode<br />
021f3c: tornamentmodecheck<br />
00e1b0: tornamenttog<br />
039690: tournamentcontinue<br />
03dcc4: tqmsg<br />
022008: trackdataupdate<br />
017390: trackedit<br />
046944: trackmatrix<br />
047a6c: tracknum<br />
019c20: trackoverlapcheck<br />
02ee48: transform<br />
02eff8: transmult<br />
03468b: transparentpf<br />
02fcf4: transparentpoly<br />
034678: transparentpolyf<br />
02fd04: transparentpolyi<br />
02fd14: transparentpolyip<br />
02fd24: transparentpolyipt<br />
02fd34: transparentpolyit<br />
03473b: transparentpolyp<br />
034720: transparentpolypt<br />
02fd44: transparentpolyt<br />
02f0d2: transpose<br />
046988: trkcamera<br />
04697c: trkcamerag<br />
046978: trkcamerah<br />
04698c: trksign<br />
046984: trksignh<br />
046980: trksignt<br />
047966: truckdoor<br />
0476d4: txs<br />
047710: txsh<br />
0475e4: tzline<br />
04765c: tzs<br />
047698: tzsh<br />
02459c: unflip<br />
024e24: unhuff<br />
0252dc: unlockedmemory<br />
024d60: unpacksize<br />
024d80: unpacksizea<br />
024d70: unpacksizez<br />
024df4: unrunpack<br />
0204d8: updateengine<br />
016440: updatemouseunder<br />
0165b0: usebuffer<br />
0165c0: usebufferc<br />
0479e1: usedash<br />
0479e3: usereplay<br />
016598: usescreen<br />
0165a0: usescreenc<br />
0233b4: validchar<br />
024ec8: validdrive<br />
03b8c0: vcew21<br />
03b8ac: vcns21<br />
0245ac: vertflip<br />
026aa1: vertsync<br />
026ab0: vertsyncend<br />
026aa1: vertsyncstart<br />
0349b0: vfprintf<br />
0269f8: vgapalette<br />
0269f8: vgapalettefar<br />
051370: videopage<br />
05136c: videowindow<br />
024910: videowindowdef<br />
047970: viewheading<br />
047a04: voicefile<br />
0349ec: vprintf<br />
034a88: vsprintf<br />
026abf: vsyncstate<br />
03113b: waitbios<br />
0310f6: waitbiosticks<br />
01657c: waitforkey<br />
02fa74: waitticks<br />
04792a: wall<br />
0479d8: wall2sided<br />
047930: wallh<br />
047934: wallhgtb<br />
047932: wallhgtt<br />
046928: walls<br />
04792c: wallx<br />
04792e: wallz<br />
0456ac: watch<br />
047982: water<br />
0455ba: watercar<br />
024920: whichpage<br />
024930: whichwindow<br />
00e37c: wincheck<br />
046970: winddrag1<br />
046974: winddrag2<br />
03e1c4: windotxt<br />
024714: window<br />
04796c: windowbottom<br />
0245f0: windowdef<br />
051372: windowpage<br />
04796a: windowtop<br />
025af8: wordfill<br />
025b20: wordfillf<br />
026cb4: writepixel<br />
026ba2: writepixelc<br />
0413fd: xbangle<br />
03b910: xfew11<br />
03b8fc: xfns11<br />
026910: xformx<br />
02695c: xformy<br />
0269ac: xformz<br />
03b8d4: xfsn11<br />
03b8e8: xfwe11<br />
047950: xmousemaskw<br />
04794c: xmouseshapew<br />
047948: xmouseunderw<br />
02fabc: xorbox<br />
0291d9: xorcf<br />
029400: xorcfxy<br />
029438: xorcfxya<br />
027430: xorcline<br />
025ce4: xorcursor<br />
028742: xorf<br />
028829: xorfxy<br />
028861: xorfxya<br />
02773e: xorline<br />
02ac2e: xorpackcf<br />
02ae8c: xorpackcfxy<br />
02aec4: xorpackcfxya<br />
029c57: xorpackf<br />
029d23: xorpackfxy<br />
029d5b: xorpackfxya<br />
026d47: xorpixel<br />
026c6a: xorpixelc<br />
027a01: xorrect<br />
027cd5: xorrectc<br />
041405: xproject<br />
0413f9: xscale<br />
024940: xscroll<br />
024950: xscrollwindow<br />
03e19e: xshiftflag<br />
0413ff: ybangle<br />
041607: yproject<br />
0413fb: yscale<br />
02f6cb: zclip<br />
02f6df: zclipline<br />
047918: zerotime<br />
047c04: zone4<br />
01c04c: zoneadjacent<br />
01ba44: zonecheck<br />
01c014: zoneinside<br />
01bfdc: zoneoverlap<br />
045044: zv<br />
<br />
| style="vertical-align:top; width:50%;" |<br />
01a318: ADD_OBJECT_TO_BUFFER<br />
03f938: ALLOW_MODE_CHANGE<br />
03d1c4: BARR_LIST<br />
03cd78: BLTR_LIST<br />
03a6a8: BOTButcol<br />
03ccf4: BSTR_LIST<br />
03a660: Blue<br />
03a66a: Brown<br />
03a6b2: CBlue<br />
03c948: CHI1_LIST<br />
03ca1c: CHI2_LIST<br />
03a6b4: CRed<br />
017130: ConfirmMessage<br />
03a696: CredArtCol<br />
03a698: CredArtCols<br />
03a68a: CredCreCol<br />
03a68c: CredCreCols<br />
03a68e: CredDesCol<br />
03a690: CredDesCols<br />
03a69a: CredMusCol<br />
03a69c: CredMusCols<br />
03a692: CredProCol<br />
03a694: CredProCols<br />
03a686: CredTxtCol<br />
03a688: CredTxtCols<br />
03a680: Cursorcol1<br />
03a682: Cursorcol2<br />
03a664: Cyan<br />
01b828: DRAW_OBJECTS<br />
03f668: DSK_filename<br />
03a66e: Darkgrey<br />
017180: DriveAorB<br />
0230e0: DriveRetry<br />
0476f8: Dso<br />
0487cc: Dtrackmatrix<br />
03a6b6: EBoxcol<br />
053b00: EGBWork<br />
039cf8: EGB_displayPage<br />
039c94: EGB_displayStart<br />
039c34: EGB_init<br />
039c64: EGB_resolution<br />
039ccc: EGB_writePage<br />
03f942: ErrorCS<br />
03f944: ErrorIP<br />
03a684: Evalcol2<br />
03cd20: FLBSTR_LIST<br />
03c748: FLTRR_LIST<br />
03c674: FLTR_LIST<br />
0227d8: FMTFREEMEMORY<br />
022800: FMTPURGEMEMORY<br />
04a134: FMT_cheading<br />
03c168: FMT_index<br />
04a128: FMT_inpoint<br />
020d70: FMT_loadshape<br />
020dc4: FMT_loadshapez<br />
04a130: FMT_outplace<br />
04a118: FMT_point<br />
04a120: FMT_point2<br />
019f34: FMT_printpoly<br />
04a138: FMT_render2_matrix<br />
020e18: FMT_scalecfxy<br />
03cd4c: FRBSTR_LIST<br />
03c550: FSTRI_LIST<br />
03c57c: FSTRL_LIST<br />
03c5b4: FSTRR_LIST<br />
03c480: FSTR_LIST<br />
03c630: FTURR_LIST<br />
03c5ec: FTUR_LIST<br />
03f94a: FontColor<br />
03f94c: FontColor2<br />
03f948: FontHeight<br />
03f94e: FontStyle<br />
03f946: FontWidth<br />
047714: FullName<br />
03d114: GHWY1_LIST<br />
03d140: GHWY2_LIST<br />
03a662: Green<br />
03c874: HLTR_LIST<br />
03d1fc: HPIPE_LIST<br />
03c848: HSTRI_LIST<br />
03c81c: HSTR_LIST<br />
03d16c: HWY1_LIST<br />
03d198: HWY2_LIST<br />
0498c2: HighIndex<br />
01a22c: INIT_BUFFERS<br />
01a1a4: INIT_MATRIX<br />
01a254: INIT_OBJECTS_BUFFER<br />
01a1fc: INIT_PALETTE<br />
0226d8: InitRamDrive<br />
052168: Joyport1<br />
05216c: Joyport2<br />
03a168: KYB_clic<br />
03a180: KYB_clrbuf<br />
03a124: KYB_init<br />
03a194: KYB_inpchk<br />
03a1e8: KYB_matrix<br />
03a1c0: KYB_read<br />
03a138: KYB_setbuf<br />
03a150: KYB_setcode<br />
03fc18: KanaFont16<br />
03fc78: KanaFont8<br />
03fb80: KanaFontColor16<br />
03fb86: KanaFontColor8<br />
03fb7e: KanaFontHeight16<br />
03fb84: KanaFontHeight8<br />
03fb7c: KanaFontWidth16<br />
03fb82: KanaFontWidth8<br />
03fb88: KanaShape16<br />
03fc28: KanaShape8<br />
03fb40: KanjiFont<br />
03f950: KanjiShape<br />
03a51c: KimG_getclient<br />
03a538: KimG_popclient<br />
03a508: KimG_setclient<br />
03ce4c: LCOR_LIST<br />
03fc8a: LOOPC<br />
03cb1c: LOOP_LIST<br />
03a670: Lightblue<br />
03a674: Lightcyan<br />
03a672: Lightgreen<br />
03a66c: Lightgrey<br />
03a678: Lightmagenta<br />
03a676: Lightred<br />
03a6b8: MBoxcol<br />
03a6aa: MIDButcol<br />
052a74: MOSWork<br />
03a010: MOS_disp<br />
039ef8: MOS_end<br />
03a0a0: MOS_horizon<br />
03a038: MOS_rdpos<br />
03a100: MOS_resolution<br />
03a070: MOS_setpos<br />
039d6c: MOS_start<br />
03a0d0: MOS_vertical<br />
03a668: Magenta<br />
05215c: Mosport0<br />
052160: Mosport1<br />
052164: Mosport2<br />
0239b8: MoveCurrent<br />
03c16c: NP<br />
0498b4: NewSI<br />
03a6ac: OptColor<br />
03c524: PIPE_LIST<br />
03c17c: PT<br />
04a14c: P_firstiplc<br />
04a150: P_insertlen<br />
04a14e: P_iplc<br />
04a154: P_listend<br />
04a14a: P_numpoints<br />
04a152: P_pindex<br />
049894: PlayerName<br />
051afc: RAM_file<br />
03f678: RAM_filename<br />
03f660: RAM_filesize<br />
051b0c: RAM_saved<br />
03a6ae: RBBoxcol<br />
03a6b0: RBCursorcol<br />
03cfb0: RCOR_LIST<br />
03b3c0: RPath<br />
013958: RayNullFunction<br />
03a666: Red<br />
03b414: ReplayName<br />
03fc82: SBIGINAD<br />
03a6bc: SDPAL_mcgacol1<br />
03a9c8: SDPAL_mcgacol2<br />
03a8c4: SDPAL_mcgadither<br />
03a7c0: SDPAL_mcgatype<br />
03fc86: SLINEPIX<br />
034e70: SMALL?<br />
054320: SNDWork<br />
03567c: SND_driver<br />
03570c: SND_elevol_all_mute<br />
0356fc: SND_elevol_mute<br />
0356e4: SND_elevol_set<br />
035868: SND_end<br />
035994: SND_fm_timer_a_set<br />
035760: SND_init<br />
035620: SND_inst_change<br />
0356b8: SND_inst_write<br />
035a44: SND_int_timer_a_get<br />
035a00: SND_int_timer_a_set<br />
0355ec: SND_joy_in_1<br />
03565c: SND_key_abort<br />
035608: SND_key_on<br />
035980: SND_pan_set<br />
035a4c: SND_pcm_bank_load<br />
0359a8: SND_pcm_mode_set<br />
0359b8: SND_pcm_play<br />
0359d8: SND_pcm_play_stop<br />
03566c: SND_pcm_sound_delete<br />
0356d4: SND_pcm_sound_set<br />
0359e8: SND_pcm_status<br />
035634: SND_pitch_change<br />
035648: SND_volume_change<br />
03c4f8: SPIPE_LIST<br />
058320: SaveTimer<br />
0498b0: Scores<br />
023ce8: ScreenKeybord<br />
023670: SetArray<br />
023944: SetCurrent<br />
00f1f0: ShowTitle<br />
00f2bc: ShowTitle2<br />
054100: SystemMemory<br />
045704: TBIOSSTK_bottom<br />
03a6a6: TOPButcol<br />
03b36c: TPath<br />
03c4d8: TUN_LIST<br />
03b420: TerName<br />
03a69e: TrackBoxCol1<br />
03a6a0: TrackBoxCol2<br />
03a6a2: TrackBoxCol3<br />
03a6a4: TrackCursorCol<br />
03caf0: USTR_LIST<br />
03cc44: VCORK_LIST<br />
0170cc: WarningMessage<br />
03a67c: White<br />
03c4ac: XFSTR_LIST<br />
03a67a: Yellow<br />
01707c: YesOrNoMessage<br />
044724: __mwdfc<br />
044724: __mwdlc<br />
044a34: __onexit_termination<br />
044734: _base<br />
044988: _bufsiz<br />
04460c: _ctype<br />
03694c: _dos_findfirst<br />
036980: _dos_findnext<br />
03406c: _dos_getdiskfree<br />
044b00: _doserr<br />
044afc: _doserrno<br />
046d54: _edata<br />
058490: _end<br />
036938: _exit<br />
033fd0: _fdopen<br />
044a24: _fmode<br />
0449ec: _fopen_max<br />
03a650: _fsoftonly<br />
033fec: _fsopen<br />
044748: _gda<br />
044794: _iob<br />
036a7c: _itoa<br />
044769: _mw1167<br />
03a650: _mw1167required<br />
03a650: _mw1167used<br />
03a650: _mw3167used<br />
044767: _mw387<br />
03a650: _mw387used<br />
044763: _mw8087<br />
03a650: _mw87only<br />
03a650: _mw87required<br />
03a650: _mw87used<br />
044728: _mwCPU<br />
0340a4: _mwINIT<br />
044729: _mwOS<br />
03928c: _mw_87_f2add<br />
0392b6: _mw_87_f2compare<br />
0392af: _mw_87_f2div<br />
0392a8: _mw_87_f2mpy<br />
03937a: _mw_87_fbld<br />
039370: _mw_87_fbstp<br />
0392cc: _mw_87_fflt<br />
03930c: _mw_87_flload<br />
0392f2: _mw_87_fload<br />
0392f9: _mw_87_flret<br />
039326: _mw_87_fpop<br />
0392e5: _mw_87_fret<br />
03931d: _mw_87_ftload<br />
039313: _mw_87_ftret<br />
039367: _mw_87_fxam<br />
03935c: _mw_87_round<br />
039340: _mw_87_trunc<br />
0392d3: _mw_87_ufflt<br />
034e74: _mw_errnoset<br />
044d90: _mw_findnext_uses_attrib<br />
039bc8: _mwabort<br />
039544: _mwaddmany<br />
037a10: _mwaprintf<br />
044758: _mwarglen<br />
04474c: _mwargp<br />
03a650: _mwargregs<br />
03a650: _mwargstack<br />
044752: _mwargvp<br />
038bc0: _mwbcd_to_real<br />
034c34: _mwc_create<br />
034c14: _mwc_dos_name<br />
034c5c: _mwc_open<br />
034c8c: _mwc_unlink<br />
034ec4: _mwcall_onexit_fcns<br />
03547c: _mwcalldos<br />
033974: _mwcfclose_all<br />
034940: _mwcfinit<br />
034988: _mwcfterm<br />
03545c: _mwcheck_heap_integrity<br />
034e44: _mwcmp<br />
039b98: _mwdisplay<br />
0369d8: _mwdo_itoa<br />
034b24: _mwdos<br />
034bdc: _mwdos_exit<br />
039685: _mwdshl<br />
035564: _mwdump_heap<br />
034fe8: _mweach_allocated_item<br />
034f6c: _mweach_free_item<br />
034ef8: _mweach_item<br />
04476b: _mwemc87<br />
034ca0: _mwend<br />
044774: _mwenv<br />
044fa0: _mwenvip<br />
04475c: _mwenvp<br />
04472a: _mwes<br />
0347f4: _mwexpand_heap<br />
038e9c: _mwfabs<br />
038bd8: _mwfadd<br />
039824: _mwfbld<br />
03991c: _mwfbstp<br />
039220: _mwfcmp<br />
039208: _mwfcompare<br />
03916c: _mwfcomparend<br />
03901c: _mwfdiv<br />
039010: _mwfdivr<br />
038ebc: _mwfdup<br />
035510: _mwferr<br />
034db8: _mwfileclass<br />
034b08: _mwfinit<br />
038d2c: _mwflload<br />
038cf0: _mwfload<br />
03a650: _mwfltused<br />
038ed8: _mwfmpy<br />
038e40: _mwfneg<br />
0396d4: _mwfpop<br />
039698: _mwfpstackoflo<br />
0353e3: _mwfree<br />
038e70: _mwfsub<br />
038e64: _mwfsubr<br />
034b08: _mwfterm<br />
038d68: _mwftload<br />
038dc8: _mwftret<br />
036dc0: _mwfwrite_<br />
039764: _mwfxam<br />
038e08: _mwfxch<br />
038b84: _mwget_exponent<br />
033c3c: _mwget_file_handle_and_info<br />
034926: _mwgetds<br />
036d84: _mwgetenv2<br />
034ce0: _mwhalt<br />
044779: _mwheap_expansion_enabled<br />
035350: _mwhmalloc<br />
0396b8: _mwinc_tos<br />
037164: _mwinit_buf<br />
0347b4: _mwinit_const<br />
044777: _mwinit_ver<br />
044724: _mwinput<br />
03505c: _mwinsert_into_free_chain<br />
034e70: _mwint21<br />
044762: _mwis_286<br />
0355c4: _mwkbnewline<br />
0355a8: _mwkbputs<br />
03a650: _mwldouble10<br />
03519c: _mwleast_free_memory<br />
034b98: _mwload_ds_dx<br />
034b64: _mwload_ptr<br />
03a65c: _mwloc<br />
034e00: _mwlseek<br />
039384: _mwltox<br />
0353ac: _mwmalloc<br />
03521c: _mwmalloc2<br />
0395c2: _mwnegmany<br />
0396dc: _mwnormalize<br />
03814c: _mwout_convert_dreal<br />
038878: _mwout_convert_real<br />
044726: _mwoutput<br />
037294: _mwpad_to_field_width<br />
044776: _mwprintnochipmsg<br />
04476e: _mwprognamep<br />
038ba8: _mwreal_to_bcd<br />
0340b8: _mwrestore_interrupts<br />
03947c: _mwrtox<br />
03724c: _mwsend_pad<br />
039262: _mwset_flags_after_compare<br />
033e40: _mwset_flags_etc<br />
039240: _mwset_rounding_proc<br />
034a0c: _mwset_up_args<br />
038ac4: _mwspecial_number_msg<br />
034923: _mwss<br />
044714: _mwstack_limit<br />
039c10: _mwstack_overflow<br />
035594: _mwstackdump<br />
039c04: _mwstkerr<br />
03956d: _mwsubmany112<br />
039596: _mwsubmany121<br />
038a44: _mwten_to_the_power<br />
034cc8: _mwvsretcode<br />
044775: _mwwind<br />
039b00: _mwxdiv<br />
039ab4: _mwxmpy<br />
0395e7: _mwxnormalize<br />
03961c: _mwxshl<br />
03962c: _mwxshr<br />
039638: _mwxshrcnt<br />
0393f9: _mwxtol<br />
0394e1: _mwxtor<br />
034bbc: _mwzclose<br />
034d2c: _mwzread<br />
034da4: _mwztrunc<br />
034d58: _mwzwrite<br />
03fc94: _osmajor<br />
03fc95: _osminor<br />
03fc94: _osversion<br />
04472a: _psp<br />
036a98: _strcmpi<br />
036a98: _stricmp<br />
03a554: _strnicmp<br />
037d04: _strrev<br />
0449f0: _temp_file_chain<br />
044730: _top<br />
043bb5: _zclipvalue<br />
03ba18: abbrname<br />
03bee1: abortbox<br />
02545c: abortmessage<br />
021980: accelerate<br />
041b4c: activeflag<br />
043bc8: adderr<br />
026598: addexit<br />
03fd18: addexiterr<br />
011e40: addhighs<br />
031188: addtimer<br />
021280: addtotextbuf<br />
01be40: addzone<br />
0254c8: adrtoseg<br />
052188: all<br />
0498fc: allcarobject1<br />
0499fc: allcarobject2<br />
022d64: allexist<br />
049a14: alloppresfile<br />
03b465: allowabort<br />
052154: alphashp<br />
02a44b: andcf<br />
02a672: andcfxy<br />
02a6aa: andcfxya<br />
02878a: andcline<br />
029c34: andf<br />
029d1b: andfxy<br />
029d53: andfxya<br />
028e2c: andline<br />
02be32: andpackcf<br />
02c090: andpackcfxy<br />
02c0c8: andpackcfxya<br />
02b17f: andpackf<br />
02b24b: andpackfxy<br />
02b283: andpackfxya<br />
028475: andpixel<br />
028386: andpixelc<br />
028ff1: andrect<br />
02930d: andrectc<br />
0219c4: anim_car<br />
021c64: anim_champ<br />
021744: anim_finish<br />
012164: animateopponent<br />
00eecc: animcarsmk<br />
049a3a: animdelay<br />
00eaf8: animhelmet1<br />
00ed54: animhelmet2<br />
049a32: animindex<br />
049a38: animnum<br />
049a3e: animx<br />
049a40: animy<br />
047529: askfull<br />
034e94: atexit<br />
0005a8: availmem<br />
049a2c: backfile<br />
0268a8: background<br />
019f38: benprojectp<br />
049882: between<br />
03d624: bew11<br />
058344: biosticks<br />
043c38: biostickset<br />
049814: bitplanes<br />
03f17c: blackpal<br />
0419b8: blknotfound<br />
0487e4: blocklistsign<br />
020740: blowengine<br />
041944: bmem<br />
03d688: bne22<br />
03d610: bns11<br />
03d69c: bnw22<br />
041bba: botfire<br />
00d438: boxcheck<br />
049812: bpix<br />
04986f: brakecolor<br />
03da94: brew11<br />
03da80: brns11<br />
03d660: bse22<br />
03d638: bsn11<br />
03d674: bsw22<br />
049a00: buttfile<br />
03d64c: bwe11<br />
00c820: calccoll<br />
024a2c: calcrpm<br />
03b250: camerasizeinfo<br />
03b458: camheading<br />
03b456: camlen<br />
03b45f: cammode<br />
03b45a: campitch<br />
052158: canncel_flag<br />
0254a4: cap<br />
047480: car1<br />
0497ba: car1handle<br />
049648: car1ltires<br />
0496f0: car1tcenter<br />
049660: car1toffsets<br />
0497bc: car2handle<br />
049654: car2ltires<br />
04978c: car2tcenter<br />
0496fc: car2toffsets<br />
0208f4: carbubble<br />
0207f8: carbump<br />
02079c: carcrash<br />
048190: cari<br />
048498: cari2<br />
0211b0: carmovesfx<br />
049820: carname<br />
04a984: carobjects1<br />
04a988: carobjects2<br />
03b478: carresname<br />
02084c: carscrape<br />
0208a0: carsplash<br />
03f63c: ccmsg<br />
020d40: cdfade<br />
032018: cdfadeto<br />
0321d4: cdisbusy<br />
03f634: cdmsg<br />
0321b4: cdpause<br />
0324d0: cdplay<br />
0321fc: cdplaysection<br />
032364: cdplaysector<br />
0320e8: cdprinttoc<br />
03a36c: cdr_cdinfo<br />
03a428: cdr_continue<br />
03a474: cdr_exit1<br />
03a2ec: cdr_mphase<br />
03a2d8: cdr_mstop<br />
03a274: cdr_mtplay<br />
03a414: cdr_pause<br />
03a4f0: cdr_popclient<br />
03a4d0: cdr_pushclient<br />
03a204: cdr_sdrvmd<br />
045781: cdr_stat<br />
03a240: cdr_status<br />
032040: cdreadtoc<br />
0321c4: cdresume<br />
020d2c: cdsnddone<br />
032198: cdstart<br />
0321a4: cdstop<br />
031fac: cdupdatefade<br />
0273d4: centertext<br />
0437a1: centerx<br />
0437ad: centerxpix<br />
0437a3: centery<br />
0437af: centerypix<br />
043799: cenxpix<br />
04379b: cenypix<br />
049ab0: cfcount<br />
03f638: cfmsg<br />
03d78c: ch1ew21<br />
03d7a0: ch1ns21<br />
03d7b4: ch2ew21<br />
03d778: ch2ns21<br />
022328: champion<br />
0215d4: change_palette<br />
0250d6: changeareacolor<br />
00e3b4: changedrive<br />
00e4a0: checkcarname<br />
017358: checkdisk<br />
022e6c: checkinstall<br />
026bcc: checkmodule<br />
01c3dc: checkobjtypes<br />
019c40: checktracksyntax<br />
03f49c: chmpname<br />
027124: chooseone<br />
043d48: circles<br />
043d4c: circletbls<br />
0497e0: cjoystate<br />
049ab2: clastcolor<br />
04981d: clastx<br />
04981e: clastz<br />
0166d0: clear_keyboardbuffer<br />
0000c4: clearinterpretsubs<br />
035e3c: clearscreen<br />
025d5c: clearwindow<br />
013710: clearzone<br />
026070: clip<br />
0497fe: clipby<br />
02f82b: clipline<br />
025f10: clippix<br />
025ee0: clippixwindow<br />
0497fc: clipty<br />
026080: clipwindow<br />
01bda8: clipzone<br />
015fc4: closeresource<br />
0497fa: cloudfudge<br />
04987e: cmps<br />
03dae4: colew22<br />
03daa8: colns22<br />
04a8cc: color1<br />
04a8d0: color2<br />
0514fc: colorbak<br />
0517fc: colorcur<br />
04a8d8: colordither<br />
04a8dc: colorrnds<br />
04a8d4: colorstat<br />
03dad0: colsn22<br />
03dabc: colwe22<br />
01eeac: compiletrack<br />
027628: convertjoy<br />
03f140: coord1<br />
03f148: coord2<br />
01c378: copyobj<br />
01c390: copyobjtypes<br />
022c08: copyq2a<br />
03db34: corew22<br />
03daf8: corns22<br />
03db20: corsn22<br />
03db0c: corwe22<br />
049858: countdown<br />
03f640: cpmsg<br />
019edc: cpycoord<br />
019f14: cpymatrix<br />
019efc: cpyscoord<br />
004470: crack<br />
025550: crcbyte<br />
00f364: credit1<br />
00f40c: credit2<br />
0327e7: criterr<br />
043c36: critflag<br />
043c30: critfunc<br />
03277e: crithandler<br />
03287f: ctrlc<br />
03286f: ctrlchandler<br />
03bed0: curfname<br />
04945c: curplane<br />
0498fa: currcar<br />
03f138: currchannel<br />
052a48: current<br />
03f16a: currentbuf<br />
041c82: currentfont<br />
027568: currentkeysub<br />
04220a: currentwindow<br />
04d166: currpm<br />
053aec: cursmask<br />
053ae8: cursshape<br />
047540: cusedash<br />
049869: cusereplay<br />
015140: cutpath<br />
047d14: cv<br />
048174: cvx<br />
046d58: cz<br />
049886: czoneflag<br />
03f68a: datadrive<br />
047690: dcar_matrix<br />
0497f2: dclip<br />
03b368: deffont<br />
020218: deinitenginesfx<br />
02155c: delaykey<br />
0311bc: deltimer<br />
049853: demomode<br />
03b314: demoplane<br />
0497a4: demotime<br />
049854: didrace<br />
0214f8: disabletextbuf<br />
022ab8: diskaexist<br />
0228e8: diskexist<br />
022758: diskfile<br />
02296c: diskfileerror<br />
022928: diskfileexist<br />
0265fc: diskfree<br />
03beac: diskmsgs<br />
03bebc: disknames<br />
03f688: diskop<br />
022a90: diskspace<br />
0233e8: disolve_entirememwindow<br />
023214: disolve_hiddenwindow<br />
0232e8: disolve_memwindow<br />
026f28: displayall<br />
026ed0: displayone<br />
025d2c: displayshapes<br />
025ed0: displaywindow<br />
031398: ditheredpoly<br />
0313a8: ditheredpolyf<br />
0313b8: ditheredpolyi<br />
0313c8: ditheredpolyip<br />
0313d8: ditheredpolyipt<br />
0313e8: ditheredpolyit<br />
0313f8: ditheredpolyp<br />
031408: ditheredpolypt<br />
031418: ditheredpolyt<br />
020d14: docdplay<br />
016974: docursor<br />
01695c: docursorinit<br />
0067d4: dodash<br />
00bd7c: doengine<br />
00c310: dohandling<br />
016468: dohidemouse<br />
007564: doreplay<br />
027f70: dosexit<br />
00c978: doshock<br />
0164bc: doshowmouse<br />
01602c: doslider<br />
00cad4: dosteering<br />
014dc0: draw3dboxin<br />
014c98: draw3dboxout<br />
014eec: draw3dbutton<br />
003a6c: drawblimpworld<br />
031318: drawbox<br />
035c6c: drawcircle<br />
028573: drawcline<br />
011abc: drawhighs<br />
0030d4: drawhorizon<br />
002f18: drawhorizone<br />
028ddb: drawline<br />
004e78: drawlogo<br />
049856: drawmode<br />
013744: drawmode4box<br />
0120e4: drawopponent<br />
019514: drawpiecebox<br />
035eec: drawpolyf<br />
03153c: drawpolyp<br />
031528: drawpolypt<br />
028f1f: drawrect<br />
029261: drawrectc<br />
003a08: drawsort<br />
003f94: drawtext<br />
019690: drawtrackbox<br />
000840: drawworld<br />
0005c4: drawworldflipzones<br />
02660c: drive<br />
016b70: drnd<br />
0265d0: dsiexit<br />
03f644: dsmsg<br />
04742c: dtempzone<br />
0254d0: dump<br />
026fdc: dumpone<br />
0497e8: ebufend<br />
0497e6: ebufstart<br />
0497e4: ebuftime<br />
031214: elapsedticks<br />
032c6c: ellipse<br />
033490: ellipseh<br />
01738c: elticks<br />
021504: enabletextbuf<br />
03b4e0: endgame<br />
03af30: eng<br />
03af70: eng2<br />
0477c4: enginebuffer<br />
0204d0: engineoff<br />
0203fc: engineon<br />
020a20: enginesfxover<br />
021410: erasetext<br />
0449fa: errno<br />
049a3c: et<br />
0121f0: evaluation<br />
036920: exit<br />
03fcf0: exitsub<br />
041a18: exmemerr<br />
0419e8: expanderr<br />
047408: explbmapsdiam<br />
03f6bc: ext<br />
054204: extkeysubs<br />
04a8e0: facedir<br />
0233fc: fade_display<br />
0234cc: fade_displays<br />
0338d0: fclose<br />
04d160: fcolor<br />
04d162: fcolor2<br />
03d2c0: few11<br />
0337f8: fflush<br />
0365cc: fgetc<br />
026100: filename<br />
03fce4: filerrtxt<br />
02658c: fileselector<br />
026474: filesize<br />
026494: filesizea<br />
026484: filesizez<br />
00bae0: findcar<br />
026590: findfile<br />
026138: findfirst<br />
026160: findnext<br />
00d9ec: finishgame<br />
016a18: finishsong<br />
049a30: firstone<br />
049866: firsttime<br />
0328a8: fixedmult<br />
03d5fc: flbew11<br />
03d5e8: flbns11<br />
03d5c0: flbsn11<br />
03d5d4: flbwe11<br />
0151ac: floadreq<br />
017394: fluffyload<br />
02e699: fmtandcf<br />
02e8a3: fmtandcfxy<br />
02e8cc: fmtandcfxya<br />
02e081: fmtandf<br />
02e13e: fmtandfxy<br />
02e167: fmtandfxya<br />
032a8c: fmtandpackcf<br />
032acc: fmtandpackcfxy<br />
032b0c: fmtandpackcfxya<br />
02f0c9: fmtandpackf<br />
02f197: fmtandpackfxy<br />
02f1c0: fmtandpackfxya<br />
032f16: fmtandrect<br />
0332b9: fmtandrectc<br />
035e6b: fmtclearscreen<br />
032a3c: fmtdisolvefast<br />
032a4c: fmtdisolvefastxya<br />
032a5c: fmtdisolveslow<br />
032a6c: fmtdisolveslowxya<br />
032e20: fmtdrawrect<br />
03321c: fmtdrawrectc<br />
026858: fmtenlargescreen<br />
03fcbc: fmtexten<br />
0282b0: fmtgetpalette<br />
035e9c: fmthtclear<br />
02673c: fmtinitgraphics<br />
02e465: fmtmovcf<br />
02e64f: fmtmovcfxy<br />
02e678: fmtmovcfxya<br />
02df92: fmtmovf<br />
02e037: fmtmovfxy<br />
02e060: fmtmovfxya<br />
032a7c: fmtmovpackcf<br />
032abc: fmtmovpackcfxy<br />
032afc: fmtmovpackcfxya<br />
02efbd: fmtmovpackf<br />
02f07f: fmtmovpackfxy<br />
02f0a8: fmtmovpackfxya<br />
02e8ed: fmtorcf<br />
02eaf7: fmtorcfxy<br />
02eb20: fmtorcfxya<br />
02e188: fmtorf<br />
02e245: fmtorfxy<br />
02e26e: fmtorfxya<br />
032a9c: fmtorpackcf<br />
032adc: fmtorpackcfxy<br />
032b1c: fmtorpackcfxya<br />
02f1e1: fmtorpackf<br />
02f2af: fmtorpackfxy<br />
02f2d8: fmtorpackfxya<br />
033018: fmtorrect<br />
033356: fmtorrectc<br />
028259: fmtpalette<br />
0282f0: fmtpaltocol<br />
02f74e: fmtreadf<br />
02f7c2: fmtreadfxy<br />
02f7e8: fmtreadfxya<br />
032b3c: fmtscalecf<br />
032b4c: fmtscalecfxy<br />
032b5c: fmtscalecfxya<br />
032b6c: fmtscalef<br />
032b7c: fmtscalefxy<br />
032b8c: fmtscalefxya<br />
032c3c: fmtscalereccf<br />
032c4c: fmtscalereccfxy<br />
032c5c: fmtscalereccfxya<br />
032c0c: fmtscalerecf<br />
032c1c: fmtscalerecfxy<br />
032c2c: fmtscalerecfxya<br />
026758: fmtscreenmode<br />
032b9c: fmtsetcolortranslate<br />
02df4b: fmtsetscreen<br />
029784: fmtspeed<br />
02ed95: fmttmaskcf<br />
02ef73: fmttmaskcfxy<br />
02ef9c: fmttmaskcfxya<br />
02e396: fmttmaskf<br />
02e41b: fmttmaskfxy<br />
02e444: fmttmaskfxya<br />
032bac: fmttmaskhpackcf<br />
032bbc: fmttmaskhpackcfxy<br />
032bcc: fmttmaskhpackcfxya<br />
02f5a3: fmttmaskhpackf<br />
02f701: fmttmaskhpackfxy<br />
02f72d: fmttmaskhpackfxya<br />
032bdc: fmttmaskpackcf<br />
032bec: fmttmaskpackcfxy<br />
032bfc: fmttmaskpackcfxya<br />
02f411: fmttmaskpackf<br />
02f559: fmttmaskpackfxy<br />
02f582: fmttmaskpackfxya<br />
03fce0: fmtwindotxt<br />
025f84: fmtwindowdef<br />
02eb41: fmtxorcf<br />
02ed4b: fmtxorcfxy<br />
02ed74: fmtxorcfxya<br />
02e28f: fmtxorf<br />
02e34c: fmtxorfxy<br />
02e375: fmtxorfxya<br />
032aac: fmtxorpackcf<br />
032aec: fmtxorpackcfxy<br />
032b2c: fmtxorpackcfxya<br />
02f2f9: fmtxorpackf<br />
02f3c7: fmtxorpackfxy<br />
02f3f0: fmtxorpackfxya<br />
03311a: fmtxorrect<br />
0333f3: fmtxorrectc<br />
03d348: fne11<br />
03d398: fne22<br />
03d2ac: fns11<br />
03d35c: fnw11<br />
03d3ac: fnw22<br />
0261a4: fo<br />
0497e2: fontheight<br />
03b454: fontwidest<br />
033fb4: fopen<br />
0298cb: fortext<br />
0298a7: fortextxy<br />
03686c: fprintf<br />
03d5ac: frbew11<br />
03d598: frbns11<br />
03d570: frbsn11<br />
03d584: frbwe11<br />
036540: fread<br />
0349cc: free<br />
010cd4: freealloppres<br />
00466c: freeallscene<br />
010d94: freeallselopp<br />
041938: freebotidx<br />
026bd4: freememory<br />
026bc8: freepack<br />
04193c: freetopidx<br />
026be4: freetotop<br />
027f50: frenchjoycal<br />
0230f4: fromram<br />
01b7d8: front_facing<br />
03d55c: fruew11<br />
03d534: fruns11<br />
03d520: frusn11<br />
03d548: fruwe11<br />
015a34: fsavereq<br />
049862: fscrn<br />
03d320: fse11<br />
03d370: fse22<br />
036630: fseek<br />
04d164: fstyle<br />
03d334: fsw11<br />
03d384: fsw22<br />
036714: ftell<br />
049816: fts<br />
0370ac: fwrite<br />
058358: gCDTrackTime<br />
049859: gabort<br />
0051d0: game<br />
005df8: gameint<br />
005dc0: gameintinit<br />
04a97c: gameobjects1<br />
04a980: gameobjects2<br />
03bf22: gamepauseflag<br />
0476d0: gameres<br />
011d2c: genhline<br />
0245b4: get_pstring<br />
020d0c: getanimcounter<br />
03294c: getbiostick<br />
0365fc: getc<br />
036614: getchar<br />
022660: getcurrentpalette<br />
022e44: getdrive<br />
022ebc: getdriveacd<br />
022ee4: getdriveq<br />
02977f: getds<br />
036b68: getenv<br />
032310: getframeoffset<br />
011938: getmodelname<br />
025700: getmousepos<br />
026e54: getnum<br />
0224c0: getoppfilename<br />
01b78c: getoutcode<br />
0281e8: getpalette<br />
0281e8: getpalettefar<br />
01c498: getpinfo<br />
013598: getprotection<br />
015fd4: getres<br />
015fe4: getresl<br />
00e168: getsimdata<br />
02741c: getstring<br />
02742c: getstringi<br />
031200: gettick<br />
00d0e0: gettlistpoint<br />
01e21c: getwpinfo<br />
03d50c: gew11<br />
03da6c: ghyew11<br />
03da44: ghyns11<br />
03da30: ghysn11<br />
03da58: ghywe11<br />
03d4e4: gns11<br />
048814: go<br />
00b0fc: gotosim<br />
04709c: gpbmaps<br />
03fd2c: graphicmode<br />
03b270: gravity<br />
04985a: grip<br />
049804: ground<br />
048178: gs<br />
03d4d0: gsn11<br />
03d4f8: gwe11<br />
03adac: headingzones<br />
03d3d4: hew11<br />
026090: hiddenwindow<br />
0256b4: hidemouse<br />
02663c: hideprint<br />
0497f8: highestsceneryheight<br />
041948: highwater<br />
03fd2e: hirestext<br />
03d458: hne22<br />
03d3c0: hns11<br />
03d46c: hnw22<br />
0268b8: horizsync<br />
03d714: hpew11<br />
03d700: hpns11<br />
03d430: hse22<br />
03d444: hsw22<br />
0268c8: hsyncstate<br />
03d40c: huew11<br />
03d3e8: huns11<br />
015f50: hurrykey<br />
03da1c: hyew11<br />
03da08: hyns11<br />
03abfc: hzoneEN<br />
03ac44: hzoneES<br />
03abb4: hzoneNE<br />
03ab6c: hzoneNW<br />
03ac8c: hzoneSE<br />
03acd4: hzoneSW<br />
03ad64: hzoneWN<br />
03ad1c: hzoneWS<br />
026bd0: ifmodule<br />
047534: inint<br />
01e7a8: init_3dcars<br />
01e58c: init_3dpieces<br />
00df08: init_explode<br />
0498f8: initallcar<br />
00aa64: initcar<br />
021190: initcarmovesfx<br />
0310c4: initctimer<br />
0007c4: initdrawworld<br />
0310b4: initdtimer<br />
020264: initengine<br />
0201c0: initenginesfx<br />
0266fc: initgraphics<br />
000078: initinterpretsubs<br />
0275d0: initjoy<br />
0276ac: initjoyl<br />
0276b4: initjoyr<br />
00d834: initlogo<br />
026988: initmemmax<br />
026968: initmemory<br />
026998: initmemsize<br />
0000f4: initmodes<br />
0255a4: initmouse<br />
00745c: initmousedrive<br />
01bcdc: initnm<br />
02664c: initprofile<br />
02665c: initprofsect<br />
0046a0: initscenery<br />
0136d0: initselections<br />
00ac00: initsim<br />
03251c: initsound<br />
02745c: initstatekey<br />
03111c: initstimer<br />
026708: inittext<br />
0310a4: inittimer<br />
005d90: initworld<br />
027570: inkey<br />
022c94: installa<br />
022c54: installhigtrk<br />
01395c: instringz<br />
028080: int3dhypot<br />
030485: intatan<br />
03046f: intcos<br />
03d2fc: inte11<br />
027f08: interpretclear<br />
027e48: interpretkey<br />
027eb4: interpretsub<br />
030571: inthypot<br />
04986b: intraffic<br />
0303e7: intsin<br />
03fcec: invalid<br />
047434: inwater<br />
03d6ec: ipew11<br />
03d6d8: ipns11<br />
0355dc: itoa<br />
027bac: joybuttons<br />
027dd0: joybuttonsb<br />
027f4c: joycal<br />
03b492: joycaled<br />
041b54: joycalib<br />
027f54: joycall<br />
027f5c: joycallo<br />
027f60: joycalo<br />
027f58: joycalr<br />
027f64: joycalro<br />
041b58: joyclock<br />
027790: joycos<br />
027814: joycosb<br />
027864: joycosbi<br />
0277c4: joycosi<br />
041bc6: joydown<br />
041bca: joyleft<br />
041bc8: joyleftdown<br />
041bbc: joyleftup<br />
027f3c: joyoffl<br />
027f44: joyoffr<br />
027f80: joyon<br />
047542: joypad_state<br />
041bc2: joyright<br />
041bc4: joyrightdown<br />
041bc0: joyrightup<br />
0279e4: joystate<br />
027be8: joystateb<br />
0275d8: joystick<br />
0276bc: joystickb<br />
041bbe: joyup<br />
02763c: joyxpot<br />
027718: joyxpotl<br />
027788: joyxpotr<br />
027674: joyypot<br />
027750: joyypotl<br />
02778c: joyypotr<br />
0278e0: kbdjoystate<br />
03a43c: kcdr_status<br />
027f90: keybiosticks<br />
0475e8: keybordf<br />
027fa0: keyon<br />
041b50: keyprog<br />
02748c: keystate<br />
0278b8: keystatefast<br />
02755c: keysub<br />
041a4c: keysubs<br />
027584: keyticks<br />
0275a4: keywait<br />
027fb0: keywaitbios<br />
049855: lang<br />
047544: last_joypad_state<br />
049864: lastdash<br />
049863: lastdrawmode<br />
04986c: lastintraffic<br />
04986d: lastrbox<br />
049868: lastreplay<br />
04986a: lastrpause<br />
049870: lastscenery<br />
041be2: lbotfire<br />
049800: lclipby<br />
03f630: ldmsg<br />
0476d4: ledfont<br />
01bd18: lgabs<br />
053afc: library<br />
0213f8: limity<br />
043d44: linefunct<br />
041bee: ljoydown<br />
041bf2: ljoyleft<br />
041bf0: ljoyleftdown<br />
041be4: ljoyleftup<br />
041bea: ljoyright<br />
041bec: ljoyrightdown<br />
041be8: ljoyrightup<br />
041be6: ljoyup<br />
02251c: loadalloppfile<br />
010c74: loadalloppres<br />
00462c: loadallscene<br />
010d1c: loadallselopp<br />
025a50: loadandshapepack<br />
025a70: loadandshapepacka<br />
025a60: loadandshapepackz<br />
004858: loaddrawbits<br />
0231c8: loaddrivefile<br />
02312c: loaddrivefileatz<br />
02317c: loaddrivefilez<br />
026278: loadfile<br />
026298: loadfilea<br />
02617c: loadfileat<br />
0261f0: loadfileata<br />
026190: loadfileatz<br />
026288: loadfilez<br />
007180: loadgamefiles<br />
016870: loading<br />
0224d8: loadoppfile<br />
0262e4: loadpack<br />
026304: loadpacka<br />
026448: loadpackat<br />
026470: loadpackata<br />
02645c: loadpackatz<br />
0262f4: loadpackz<br />
0003cc: loadpalandmouse<br />
022880: loadram<br />
006728: loadreplay<br />
02575c: loadshape<br />
02577c: loadshapea<br />
02576c: loadshapez<br />
006618: loadtornamenttog<br />
0497d8: loady<br />
025820: locateshape<br />
02595c: locateshapes<br />
025990: locateshapesz<br />
0258c4: locateshapez<br />
041930: lockbotidx<br />
026a28: lockedmemory<br />
041934: locktopidx<br />
03d954: loflen22<br />
03d8e8: loflnw22<br />
03d930: loflse22<br />
03d90c: loflws22<br />
03d9e4: lofres22<br />
03d978: lofrne22<br />
03d9c0: lofrsw22<br />
03d99c: lofrwn22<br />
0048ac: logo<br />
047450: logo1<br />
047468: logo2<br />
04744c: logo_ticks<br />
047498: logoclip<br />
0497f6: lowestsceneryheight<br />
03d6c4: lpew21<br />
03d6b0: lpns21<br />
0497ec: lrndtime<br />
041be0: ltopfire<br />
00e508: main<br />
005bd0: mainkey<br />
03b364: mainres<br />
01e774: makecarname<br />
01b9e4: makematrix<br />
0159b8: makename<br />
019f6c: makeobjdef<br />
016aa4: maketime<br />
01c240: makezonelist<br />
0349e8: malloc<br />
04752a: maskdash<br />
04752c: maskshapes<br />
054310: matrix<br />
04221c: maxx<br />
042220: maxy<br />
049a04: mboxfile<br />
049a90: mboxzone<br />
052a70: mbuttons<br />
043c3c: mcgacolorxlate<br />
0329ed: mcgatranslation<br />
032a12: mcgatransrange<br />
047688: mch<br />
04768a: mchit<br />
04768c: mchithdg<br />
047684: mcp<br />
047686: mcr<br />
047678: mcx<br />
04767c: mcy<br />
047680: mcz<br />
016ff0: mdosexit<br />
01735c: memerr<br />
026e2c: memmovef<br />
027154: memsizedisplay<br />
0476cc: memwindow<br />
01bd28: mergezones<br />
0139d0: messagebox<br />
04a944: mheading_matrix<br />
04221a: minx<br />
04221e: miny<br />
0498ac: miscres<br />
0474a4: miscshapes<br />
047098: miscshapes2<br />
016d64: mjoycal<br />
016d74: mjoycalx<br />
016dd0: mkeyon<br />
000000: mloadmcgaz<br />
049a0c: mm_but<br />
020fbc: mm_drawbox<br />
020f5c: mm_drawcursor<br />
020ea0: mm_drawline<br />
020ec8: mm_drawrect<br />
020f34: mm_drawrectc<br />
020ff8: mm_fortextxy<br />
021078: mm_fshadowtext<br />
021038: mm_movtxy<br />
04a958: mmatrix<br />
016e34: mmouseon<br />
016ef8: mmusictog<br />
016e90: mnullfunc<br />
046d54: mnumzones<br />
03fd30: moddir<br />
0216b8: mode1off<br />
021660: mode1on<br />
03bbd0: modelname<br />
0514a4: modematrix<br />
0005b4: modsize<br />
026c64: modulesize<br />
025560: monocursor<br />
04570c: mos_control_flg<br />
045708: mos_event_adr<br />
045710: moswork_adr<br />
045714: moswork_seg<br />
03b462: mouseactive<br />
0497de: mouseb<br />
01666c: mousecursor<br />
03b45c: mousedrive<br />
03fcb4: mouseflag<br />
0497c8: mousemaskw<br />
01644c: mouseoff<br />
016428: mouseon<br />
03b463: mouseonscreen<br />
03b461: mouseonstat<br />
0497c4: mouseshapew<br />
03fcb8: mouseshown<br />
0074ac: mousesteer<br />
0497c0: mouseunderw<br />
0497da: mousex<br />
0497dc: mousey<br />
02a1de: movcf<br />
02a3e3: movcfxy<br />
02a41b: movcfxya<br />
00e06c: move_explode<br />
00dc54: move_on_plane<br />
008ef0: movecar<br />
005fdc: moveeverything<br />
006394: movehelicopters<br />
00d9e4: movelogo<br />
0087fc: moveopponent<br />
00b3d0: moveplayer<br />
00b1c0: movesim<br />
029b02: movf<br />
02743c: movftxy<br />
029bcc: movfxy<br />
029c04: movfxya<br />
049444: movp<br />
02bb73: movpackcf<br />
02bdca: movpackcfxy<br />
02be02: movpackcfxya<br />
02b052: movpackf<br />
02b117: movpackfxy<br />
02b14f: movpackfxya<br />
029a0a: movt<br />
0299e6: movtxy<br />
049abc: mpactive<br />
04a930: mpitch_matrix<br />
049ab4: mpstat<br />
03bf94: mpush<br />
017350: mretryhandler<br />
04a91c: mroll_matrix<br />
0171d0: msetrender<br />
0487c4: msong<br />
016f74: msoundtog<br />
0474a8: msteerx<br />
0474e8: msteerxvalid<br />
016e94: msystempause<br />
03b45d: musicon<br />
027fc0: musictog<br />
0487c0: mvoice<br />
052a6c: mx<br />
052a6e: my<br />
015120: mycenter<br />
016a4c: myclearfont<br />
047538: myclipzone<br />
000074: myfinddone<br />
000010: myfindfirst<br />
00006c: myfindnext<br />
024a99: mygetseeds<br />
0168b8: myitoa<br />
015c54: mykey<br />
0167ec: mykeywait<br />
016b98: myload<br />
016c58: myloadat<br />
01c3a8: mymemcmp<br />
04a98c: myobj<br />
024ab4: myrandom<br />
03b468: myseed<br />
016a2c: mysetfont<br />
024a7e: mysetseeds<br />
00cbe0: myupdatesfx<br />
00d07c: myupdatesfx1<br />
00d040: myupdatesfx2<br />
046ed0: mz<br />
047038: mzkey<br />
015b68: namecopy<br />
022f34: namedrive<br />
03f650: ndmsg<br />
026a84: negblockmove<br />
027514: nextkey<br />
03f658: nlmsg<br />
049880: nmps<br />
041984: noblkerr<br />
03b45e: nohandling<br />
04194c: nomemerr<br />
03becc: noreadpacket<br />
01bc0c: norm_zone<br />
0274cc: normkey<br />
0277f8: normkeyi<br />
054104: normkeysubs<br />
03fcd8: norowspc<br />
03fce8: notpack<br />
049810: npix<br />
03f65c: nrmsg<br />
03f654: nsmsg<br />
025548: nullfunction<br />
02554c: nullprint<br />
03c234: nullzone<br />
03a67e: numcolors<br />
027f68: numlockclear<br />
027fd0: numlockset<br />
0497a0: numroadblocks<br />
049818: numtrkcameras<br />
049819: numtrksigns<br />
049884: nzoneflag<br />
04a990: objtype1<br />
04bd18: objtype2<br />
03db48: objtypes<br />
03d834: oflen11<br />
03d7c8: oflnw11<br />
03d810: oflse11<br />
03d7ec: oflws11<br />
03d8c4: ofres11<br />
03d858: ofrne11<br />
03d8a0: ofrsw11<br />
03d87c: ofrwn11<br />
03b360: oldlist<br />
015f60: openresource<br />
022558: oppanim<br />
0514e0: oppfile<br />
03f610: oppfilename<br />
049850: oppinit<br />
03b470: oppname<br />
01fecc: opponentcompile<br />
0487f0: opponentlist<br />
0487b0: oppspeeds<br />
005fb0: optimizejoystick<br />
005f7c: optimizejoyxpot<br />
01164c: options<br />
02a6da: orcf<br />
02a901: orcfxy<br />
02a939: orcfxya<br />
0289a5: orcline<br />
029d83: orf<br />
029e6a: orfxy<br />
029ea2: orfxya<br />
028e7d: orline<br />
02c0f8: orpackcf<br />
02c356: orpackcfxy<br />
02c38e: orpackcfxya<br />
02b2b3: orpackf<br />
02b37f: orpackfxy<br />
02b3b7: orpackfxya<br />
0284a6: orpixel<br />
0283c0: orpixelc<br />
0290c1: orrect<br />
0293b9: orrectc<br />
026d84: packmemory<br />
042206: pagedwindow<br />
0260a0: pageflip<br />
03aacc: palcol1<br />
03aad0: palcol2<br />
03aad8: paldither<br />
0268d8: palettecolor<br />
03aad4: palstat<br />
020e80: paltocol<br />
049860: passed<br />
053af0: pauseflag<br />
032650: pausesound<br />
0326d4: pcmdone<br />
032668: pcmstart<br />
0326c4: pcmstop<br />
00decc: pdist<br />
04980c: penalty<br />
04981f: penaltytime<br />
049817: pflip<br />
0514a0: pict<br />
04980e: pix<br />
04222a: pixmaxx<br />
042228: pixminx<br />
00de3c: plane_distance<br />
0487a8: planes<br />
016a04: playsong<br />
043c2c: pm_ceoff<br />
043c34: pm_cesel<br />
0497a6: pnum<br />
0497a8: pobjx<br />
0497aa: pobjy<br />
0497ac: pobjz<br />
023bf4: pointinarray<br />
023c30: pointsetarray<br />
03b268: pointsizeinfo<br />
045200: polling_sub_int<br />
03158d: poly<br />
031590: polycmn<br />
043d3e: polycolor2<br />
043d40: polyfunct<br />
043d3c: polymask<br />
031562: polyp<br />
01b694: polysort<br />
026a10: poolmemory<br />
026a58: posblockmove<br />
029554: print<br />
0296e4: printattribute<br />
029703: printbyte<br />
029722: printbytexy<br />
029741: printchar<br />
029760: printcharxy<br />
029511: printclear<br />
02661c: printdivby0<br />
036848: printf<br />
0296c5: printscroll<br />
023598: printsjis<br />
02361c: printsk8<br />
0296a6: printxy<br />
02666c: profileoff<br />
02667c: profileon<br />
02668c: profsectoff<br />
02669c: profsecton<br />
030d14: projectc<br />
030939: projectorgp<br />
030ae1: projectp<br />
016d2c: pullmouse<br />
022540: purgealloppfile<br />
02757c: purgekey<br />
026bf4: purgememory<br />
022504: purgeoppfile<br />
0324e8: purgesound<br />
016d04: pushmouse<br />
024b3b: putsjis<br />
025013: putsk8<br />
024e3e: putskana16<br />
024f01: putskana8<br />
026978: quitmemory<br />
02562c: quitmouse<br />
03bece: r_bgcolor<br />
0498f2: raceresult<br />
0339d8: rand<br />
031f2c: random<br />
031428: randompoly<br />
031438: randompolyf<br />
031448: randompolyi<br />
031458: randompolyip<br />
031468: randompolyipt<br />
031478: randompolyit<br />
031488: randompolyp<br />
031498: randompolypt<br />
0314a8: randompolyt<br />
041bce: rbotfire<br />
005198: read_joypad<br />
02de53: readf<br />
02ded3: readfxy<br />
02df0b: readfxya<br />
0268e8: readhiddenscreen<br />
011988: readhighs<br />
025580: readmonoatt<br />
025570: readmonochar<br />
025658: readmouse<br />
028508: readpixel<br />
0268f8: readscreen<br />
026908: redshift<br />
01ec60: remove_3dcars<br />
01e740: remove_3dpieces<br />
00489c: removedrawbits<br />
0073e4: removegamefiles<br />
005de0: removegameint<br />
00482c: removescenery<br />
025e98: removewindow<br />
04a104: render_matrix<br />
03b464: renderlevel<br />
049a50: replay_flag<br />
049460: replaybuff<br />
0474a0: replaybuflen<br />
049464: replayso<br />
026ab4: reservememory<br />
021264: resetalltextbuf<br />
032838: resetcriterr<br />
0265f8: resetdivby0<br />
0266ac: resetprofile<br />
0266bc: resetprofsect<br />
027484: resetstatekey<br />
02123c: resettextbuf<br />
031228: resettick<br />
026cac: resizememory<br />
000588: resmem<br />
014b24: restoreboxwindow<br />
0272e0: restorefont<br />
021118: restorefont4<br />
022694: restorepalette<br />
02138c: restoretext<br />
021510: restoretextbox<br />
021348: restoretextgraphic<br />
021468: restoretextwindow<br />
031174: restoretimer<br />
025f68: restorewindow<br />
03265c: resumesound<br />
023b44: reverse_edge<br />
036780: rewind<br />
0328c0: ring<br />
041bda: rjoydown<br />
041bde: rjoyleft<br />
041bdc: rjoyleftdown<br />
041bd0: rjoyleftup<br />
041bd6: rjoyright<br />
041bd8: rjoyrightdown<br />
041bd4: rjoyrightup<br />
041bd2: rjoyup<br />
043c28: rm_cevec<br />
0487a0: rndseed<br />
04979e: rndtime<br />
0487d4: roadlistc<br />
0487d8: roadlistld<br />
0487e8: roadlistp1<br />
0487ec: roadlistp2<br />
0487dc: roadlistx<br />
0487e0: roadlistz<br />
0200c4: roadupcheck<br />
042216: rowtbl<br />
049857: rpause<br />
04987c: rpfxrate<br />
04985e: rspeed<br />
041bcc: rtopfire<br />
0494a4: rtzline<br />
03d494: ruew11<br />
03d480: runs11<br />
03d4a8: rusn11<br />
03d4bc: ruwe11<br />
031885: s1linex<br />
0317c3: s1linexc<br />
0319df: s2linex<br />
0227a0: sameext<br />
03afb0: samplefile<br />
014a30: saveboxwindow<br />
021374: savecurrenttextwindow<br />
023050: savedrivefile<br />
022fc0: savedrivefilez<br />
030f43: savefile<br />
030f57: savefilez<br />
022ac8: savefloppy<br />
0272d0: savefont<br />
0210e4: savefont4<br />
012054: savehighs<br />
0173f8: saveobject<br />
02267c: savepalette<br />
0266cc: saveprofile<br />
0266dc: saveprofsect<br />
022828: saveram<br />
022d3c: saveramfiles<br />
006788: savereplay<br />
021330: savetextgraphic<br />
021304: savetextwindow<br />
021350: savetextzone<br />
025f4c: savewindow<br />
02d6cf: scalecf<br />
02d858: scalecfxy<br />
02d88d: scalecfxya<br />
02d54a: scalef<br />
02d679: scalefxy<br />
02d6ae: scalefxya<br />
02dae8: scalereccf<br />
02ddd6: scalereccfxy<br />
02de32: scalereccfxya<br />
02d8ae: scalerecf<br />
02da6b: scalerecfxy<br />
02dac7: scalerecfxya<br />
032706: scalethicknessxp<br />
032722: scalethicknessyp<br />
027fe0: scancode<br />
049848: scarname<br />
047438: scenefile<br />
03aeb2: sceneloaded<br />
047414: scenery<br />
047424: sceneryh<br />
03b460: sceneryloaded<br />
047410: sceneshapes<br />
042222: scrbyts<br />
026928: screenorigin<br />
026918: screensnap<br />
04222c: screenwindow<br />
053aa0: screenwindowsec<br />
053ac4: screenwindowvga<br />
016828: screenwipe<br />
04220a: scrfrm<br />
049798: scriptindex<br />
04979a: scriptindexend<br />
049861: scrn<br />
049a08: scrnfile<br />
03b35c: scrnlist<br />
026938: scrolldown<br />
026948: scrollup<br />
04220e: scrseg<br />
042226: scrxpixels<br />
053afe: sectionnumber<br />
043bf8: seed<br />
00035c: seedrandom<br />
0254c0: segtoadr<br />
00f64c: select<br />
00fe8c: selectcar<br />
010dd0: selectopponent<br />
021230: selecttextbuf<br />
0498c4: selofile<br />
0498c8: seloshapes<br />
032964: setbiosticks<br />
0215bc: setblackpal<br />
0226ac: setblacktext<br />
0265f4: setdivby0<br />
0272f0: setfont<br />
027ff0: setjoykeys<br />
028000: setjoykeysl<br />
028010: setjoykeysr<br />
025634: setmousebounds<br />
0256d8: setmousepos<br />
0255a0: setmouseratio<br />
025734: setmousex<br />
025748: setmousey<br />
0324e4: setmusicabort<br />
030c51: setprojectc<br />
03099a: setprojectp<br />
030978: setprojectpb<br />
0314b8: setrandompix<br />
031234: setticks<br />
01ecf4: settires<br />
027f6c: settypeahead<br />
030f28: setzclip<br />
03b260: sfpostsizeinfo<br />
04988c: sfxfile<br />
032570: sfxoff<br />
032590: sfxon<br />
049871: sfxstat<br />
049872: sfxstat1<br />
049873: sfxstat2<br />
0325b0: sfxtoggle<br />
024a5d: sgn<br />
01676c: shadowtext<br />
0259c4: shapecount<br />
025a24: shapename<br />
025ad4: shapepack<br />
0259d0: shapepointer<br />
025380: shellsort<br />
026958: shiftscreen<br />
025690: showmouse<br />
0266ec: showprint<br />
03fcd0: shperrmsg<br />
03b258: signsizeinfo<br />
0043a0: sink<br />
03f7c8: sjistable<br />
052170: sk_str<br />
045704: skb_event_adr<br />
049802: sky<br />
02f819: slopeline<br />
0476d8: smallfont<br />
04985f: smdelay<br />
03fcd4: snderrmsg<br />
0476dc: so<br />
04985b: solid<br />
032df8: solidellipseh<br />
020a98: solidtire<br />
049890: songfile<br />
0325d4: songoff<br />
0325fc: songon<br />
032640: songover<br />
032624: songtoggle<br />
01c318: sortzonelist<br />
03567c: sound_bios<br />
0356a0: sound_bios2<br />
028020: soundoff<br />
028030: soundon<br />
028040: soundtog<br />
049808: speedocol<br />
03d764: spew11<br />
03d73c: spns11<br />
0368f8: sprintf<br />
03d728: spsn11<br />
03d750: spwe11<br />
033a00: srand<br />
0311f8: sseqds<br />
04985d: staging<br />
028050: standardkeys<br />
041c86: standfont<br />
0497a2: startblockhdg<br />
04981a: startblockx<br />
04981c: startblocky<br />
04981b: startblockz<br />
02114c: startcarsfx<br />
020720: startengine<br />
020948: startskid<br />
0209a4: startskid2<br />
041b78: statekey<br />
041b98: statekeyb<br />
047548: status<br />
049878: steerval<br />
020730: stopengine<br />
020a00: stopskid<br />
033ad0: strcat<br />
033b94: strchr<br />
033a0c: strcpy<br />
016014: strcpyfar<br />
0355e4: stricmp<br />
033b38: strncmp<br />
033a50: strncpy<br />
039c2c: strnicmp<br />
025590: structshellsortup<br />
041bf4: suppressprint<br />
03f62c: svmsg<br />
049a54: sw<br />
043c20: swSFX<br />
043c24: swSong<br />
03b466: swindowindex<br />
021620: switch_palette<br />
049a74: swmemerror<br />
03f648: swmsg<br />
049a78: swwindow<br />
049874: swwindowtbl<br />
01a00c: symTransf<br />
028060: systempause<br />
046dd0: sz<br />
046e48: szalt<br />
047094: szheading<br />
04980a: tcamlen<br />
04768e: tclipy<br />
04714c: td<br />
047150: tdraw<br />
047110: tdrawindex<br />
0470b0: tdrawnum<br />
0470b4: tdrawobj<br />
0470d4: tdrawsvalue<br />
00f858: teditmain<br />
049a34: tempshape<br />
047774: tempstring<br />
03b450: terheight<br />
0487d0: terrain<br />
0329a0: testbiosticks<br />
0274c4: testkey<br />
031258: testticks<br />
04d170: textbuf<br />
041c80: textchr<br />
0299b2: textchrxy<br />
02729c: textcolor<br />
03f16c: textend<br />
0272fc: textnpixels<br />
027378: textpixels<br />
0272b4: textposition<br />
03f168: textwindowoff<br />
04d168: textzone<br />
03d2e8: tfew11<br />
03d2d4: tfns11<br />
0495d0: tfzs<br />
04960c: tfzsh<br />
0326ec: thickness<br />
03273e: thicknessxp<br />
03275e: thicknessyp<br />
031208: tickcount<br />
058324: ticks<br />
058328: tickset<br />
05832c: tickval<br />
028070: timedmessage<br />
031274: timedwait<br />
0451f4: timer_a_int<br />
0451f8: timer_b_int<br />
0451fc: timer_sub_int<br />
031018: timerint<br />
03105c: timerintb<br />
020a40: tire<br />
0498f4: titlefile<br />
0498a8: titleptr<br />
00f4b4: titles<br />
02abf8: tmaskcf<br />
02adcc: tmaskcfxy<br />
02ae04: tmaskcfxya<br />
02a021: tmaskf<br />
02a0ab: tmaskfxy<br />
02a0e3: tmaskfxya<br />
02cdd1: tmaskhpackcf<br />
02d12c: tmaskhpackcfxy<br />
02d167: tmaskhpackcfxya<br />
02b836: tmaskhpackf<br />
02b976: tmaskhpackfxy<br />
02b9b1: tmaskhpackfxya<br />
02c684: tmaskpackcf<br />
02c9ca: tmaskpackcfxy<br />
02ca02: tmaskpackcfxya<br />
02b51b: tmaskpackf<br />
02b64d: tmaskpackfxy<br />
02b685: tmaskpackfxya<br />
02ae34: tmaskxcf<br />
02b008: tmaskxcfxy<br />
02b031: tmaskxcfxya<br />
02a113: tmaskxf<br />
02a194: tmaskxfxy<br />
02a1bd: tmaskxfxya<br />
02d197: tmaskxhpackcf<br />
02d4fd: tmaskxhpackcfxy<br />
02d529: tmaskxhpackcfxya<br />
02b9e1: tmaskxhpackf<br />
02bb26: tmaskxhpackfxy<br />
02bb52: tmaskxhpackfxya<br />
02ca32: tmaskxpackcf<br />
02cd87: tmaskxpackcfxy<br />
02cdb0: tmaskxpackcfxya<br />
02b6b5: tmaskxpackf<br />
02b7ec: tmaskxpackfxy<br />
02b815: tmaskxpackfxya<br />
041940: tmem<br />
058330: tmrsub<br />
022f0c: togdrive<br />
022f90: toobig<br />
041bb8: topfire<br />
03b480: tornamentflag<br />
00e258: tornamentload<br />
03b482: tornamentmode<br />
022384: tornamentmodecheck<br />
00e270: tornamenttog<br />
03afc0: tournamentcontinue<br />
03f64c: tqmsg<br />
022450: trackdataupdate<br />
017524: trackedit<br />
0487c8: trackmatrix<br />
0498f0: tracknum<br />
019d9c: trackoverlapcheck<br />
03061f: transform<br />
0307cf: transmult<br />
035f97: transparentpf<br />
0314c8: transparentpoly<br />
035f84: transparentpolyf<br />
0314d8: transparentpolyi<br />
0314e8: transparentpolyip<br />
0314f8: transparentpolyipt<br />
031508: transparentpolyit<br />
036047: transparentpolyp<br />
03602c: transparentpolypt<br />
031518: transparentpolyt<br />
0308a9: transpose<br />
04880c: trkcamera<br />
048800: trkcamerag<br />
0487fc: trkcamerah<br />
048810: trksign<br />
048808: trksignh<br />
048804: trksignt<br />
0497ea: truckdoor<br />
02516e: twomicechk<br />
049558: txs<br />
049594: txsh<br />
049468: tzline<br />
0494e0: tzs<br />
04951c: tzsh<br />
025d3c: unflip<br />
026594: unhuff<br />
026a40: unlockedmemory<br />
0264f4: unpacksize<br />
026514: unpacksizea<br />
026504: unpacksizez<br />
026588: unrunpack<br />
020654: updateengine<br />
0165d4: updatemouseunder<br />
016744: usebuffer<br />
016754: usebufferc<br />
049865: usedash<br />
049867: usereplay<br />
01672c: usescreen<br />
016734: usescreenc<br />
024590: validchar<br />
02662c: validdrive<br />
03d248: vcew21<br />
03d234: vcns21<br />
025d4c: vertflip<br />
028231: vertsync<br />
028240: vertsyncend<br />
028231: vertsyncstart<br />
0367ec: vfprintf<br />
028188: vgapalette<br />
028188: vgapalettefar<br />
053af8: videopage<br />
053af4: videowindow<br />
0260b0: videowindowdef<br />
0497f4: viewheading<br />
049888: voicefile<br />
036828: vprintf<br />
0368c4: vsprintf<br />
02824f: vsyncstate<br />
0329c7: waitbios<br />
032982: waitbiosticks<br />
016710: waitforkey<br />
031248: waitticks<br />
0497ae: wall<br />
04985c: wall2sided<br />
0497b4: wallh<br />
0497b8: wallhgtb<br />
0497b6: wallhgtt<br />
0487ac: walls<br />
0497b0: wallx<br />
0497b2: wallz<br />
047528: watch<br />
049806: water<br />
047436: watercar<br />
0260c0: whichpage<br />
0260d0: whichwindow<br />
00e43c: wincheck<br />
0487f4: winddrag1<br />
0487f8: winddrag2<br />
03fcdc: windotxt<br />
025eb4: window<br />
0497f0: windowbottom<br />
025d90: windowdef<br />
053afa: windowpage<br />
0497ee: windowtop<br />
027260: wordfill<br />
027288: wordfillf<br />
028444: writepixel<br />
028332: writepixelc<br />
0437a9: xbangle<br />
03d298: xfew11<br />
03d284: xfns11<br />
0280a0: xformx<br />
0280ec: xformy<br />
02813c: xformz<br />
03d25c: xfsn11<br />
03d270: xfwe11<br />
0497d4: xmousemaskw<br />
0497d0: xmouseshapew<br />
0497cc: xmouseunderw<br />
031290: xorbox<br />
02a969: xorcf<br />
02ab90: xorcfxy<br />
02abc8: xorcfxya<br />
028bc0: xorcline<br />
02744c: xorcursor<br />
029ed2: xorf<br />
029fb9: xorfxy<br />
029ff1: xorfxya<br />
028ece: xorline<br />
02c3be: xorpackcf<br />
02c61c: xorpackcfxy<br />
02c654: xorpackcfxya<br />
02b3e7: xorpackf<br />
02b4b3: xorpackfxy<br />
02b4eb: xorpackfxya<br />
0284d7: xorpixel<br />
0283fa: xorpixelc<br />
029191: xorrect<br />
029465: xorrectc<br />
0437b1: xproject<br />
0437a5: xscale<br />
0260e0: xscroll<br />
0260f0: xscrollwindow<br />
03fcb6: xshiftflag<br />
0437ab: ybangle<br />
0439b3: yproject<br />
0437a7: yscale<br />
030ea2: zclip<br />
030eb6: zclipline<br />
04979c: zerotime<br />
049a88: zone4<br />
01c1c8: zoneadjacent<br />
01bbc0: zonecheck<br />
01c190: zoneinside<br />
01c158: zoneoverlap<br />
046ec0: zv<br />
|}<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5814Compression2024-01-23T17:23:17Z<p>Dstien: /* Huffman coding */ Emphasis on the codebook being canonical.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | DSI packing !! rowspan=2 colspan=2 | EAC packing !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness !! Huffman !! BPE<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || || ||<br />
|}<br />
<br />
== DSI packing ==<br />
The original release of Stunts for MS DOS uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports. The format does not have any identification bytes, so we will refer to it as ''DSI packing'' as it appeared in several DSI games in the late 80's and early 90's.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level. The codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically], meaning that the symbols in the alphabet are sorted by code length and symbol value. This makes it possible to decode the data without constructing and traversing the tree structure, instead relying on an offset table.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. Benefiting from the canonical nature of the codebook, Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that is the level's offset in the alphabet minus the tree's total capacity up to each level, and thus can be added to a code with the same level in order to get its index in the alphabet. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file, and it is still far more efficient than traversing a binary tree.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== EAC packing ==<br />
Pixel graphics in the PC98 port and non-3d shape resource files in the Amiga port uses another in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA Canada's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''EAC packing'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC BPE || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga Huffman || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga Huffman || <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt><br />
|-<br />
| Stunts Amiga BPE || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 BPE || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits !! Amiga !! PC98 !! Mickey<br />
|-<br />
| rowspan=2 | 0x4 Huffman coding<br />
| <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| rowspan=7 | 0x8 Byte pair encoding<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x45</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">101</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| rowspan=3 | 0xC Obfuscation<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| 0xD Store<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center | X<br />
|}<br />
<br />
==== 0x4 Huffman coding ====<br />
Similar to, but incompatible with the Huffman coding used in later EA games as method 0x6 and [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-huffman.htm documented by Martin Korth].<br />
<br />
==== 0x8 Byte pair encoding ====<br />
[https://en.wikipedia.org/wiki/Byte_pair_encoding Byte pair encoding] replaces frequently occurring byte pairs with a single byte that is not used elsewhere in the data. The process is repeated recursively until there are no more repeated byte pairs or available code bytes. Appears to be the same format as [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-bpe.htm documented by Martin Korth].<br />
<br />
==== 0xC Obfuscation ====<br />
Very simple data obfuscation scheme where each byte is subtracted from the previous. The process is reversed by adding running bytes as they are copied.<br />
<br />
==== 0xD Store ====<br />
Data is embedded without any transformations.<br />
<br />
== RPck ==<br />
3-d shapes in the Amiga port are compressed with RPck, a simple byte-oriented [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format also found in earlier Amiga games from DSI. Compression ratio is inferior to EAC's BPE or Huffman compression. RPck may have been kept for performance reasons or deadline constraints.<br />
<br />
<span class="hlC">// Big endian byte ordering.</span><br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">char</span> magic<span class="hlB">[</span>4<span class="hlB">]</span> <span class="hlC">// "RPck" or "Rpck"</span><br />
<span class="hlP">uint32</span> uncompressed_size<br />
<span class="hlP">uint32</span> bytes_saved<br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
After the header comes a one-byte control code treated as a signed integer. If the value is negative, it is negated and this number of bytes is read and copied directly to the output. Since the maximum length is 128, another control code is needed if there are more than 128 consecutive bytes without repetition. If the control byte value is positive, the following byte is copied to the output and then duplicated the number of times specified in the control byte. This is repeated until <tt>uncompressed_size</tt> is reached or there is no more data in the source buffer.<br />
<br />
The game is also shipped with two files, ''stdapmin.psh'' and ''stdbaudi.psh'', which appears to be wrapped in another variant of this format. The header is "<tt>PPkc</tt>" [''sic.''] and the contents are stored without compression, but the length header is stripped from the wrapped resource files. Yet another possibly related format appears in the DSI game [https://www.mobygames.com/game/107/test-drive/ Test Drive] with the header "<tt>Pckd</tt>".<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5813Compression2024-01-23T16:46:08Z<p>Dstien: Rename formats to "DSI packing" and "EAC packing" as these specifications are valid for many DSI/EA games.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | DSI packing !! rowspan=2 colspan=2 | EAC packing !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness !! Huffman !! BPE<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || || ||<br />
|}<br />
<br />
== DSI packing ==<br />
The original release of Stunts for MS DOS uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports. The format does not have any identification bytes, so we will refer to it as ''DSI packing'' as it appeared in several DSI games in the late 80's and early 90's.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== EAC packing ==<br />
Pixel graphics in the PC98 port and non-3d shape resource files in the Amiga port uses another in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA Canada's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''EAC packing'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC BPE || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga Huffman || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga Huffman || <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt><br />
|-<br />
| Stunts Amiga BPE || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 BPE || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits !! Amiga !! PC98 !! Mickey<br />
|-<br />
| rowspan=2 | 0x4 Huffman coding<br />
| <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| rowspan=7 | 0x8 Byte pair encoding<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x45</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">101</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| rowspan=3 | 0xC Obfuscation<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| 0xD Store<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center | X<br />
|}<br />
<br />
==== 0x4 Huffman coding ====<br />
Similar to, but incompatible with the Huffman coding used in later EA games as method 0x6 and [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-huffman.htm documented by Martin Korth].<br />
<br />
==== 0x8 Byte pair encoding ====<br />
[https://en.wikipedia.org/wiki/Byte_pair_encoding Byte pair encoding] replaces frequently occurring byte pairs with a single byte that is not used elsewhere in the data. The process is repeated recursively until there are no more repeated byte pairs or available code bytes. Appears to be the same format as [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-bpe.htm documented by Martin Korth].<br />
<br />
==== 0xC Obfuscation ====<br />
Very simple data obfuscation scheme where each byte is subtracted from the previous. The process is reversed by adding running bytes as they are copied.<br />
<br />
==== 0xD Store ====<br />
Data is embedded without any transformations.<br />
<br />
== RPck ==<br />
3-d shapes in the Amiga port are compressed with RPck, a simple byte-oriented [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format also found in earlier Amiga games from DSI. Compression ratio is inferior to EAC's BPE or Huffman compression. RPck may have been kept for performance reasons or deadline constraints.<br />
<br />
<span class="hlC">// Big endian byte ordering.</span><br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">char</span> magic<span class="hlB">[</span>4<span class="hlB">]</span> <span class="hlC">// "RPck" or "Rpck"</span><br />
<span class="hlP">uint32</span> uncompressed_size<br />
<span class="hlP">uint32</span> bytes_saved<br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
After the header comes a one-byte control code treated as a signed integer. If the value is negative, it is negated and this number of bytes is read and copied directly to the output. Since the maximum length is 128, another control code is needed if there are more than 128 consecutive bytes without repetition. If the control byte value is positive, the following byte is copied to the output and then duplicated the number of times specified in the control byte. This is repeated until <tt>uncompressed_size</tt> is reached or there is no more data in the source buffer.<br />
<br />
The game is also shipped with two files, ''stdapmin.psh'' and ''stdbaudi.psh'', which appears to be wrapped in another variant of this format. The header is "<tt>PPkc</tt>" [''sic.''] and the contents are stored without compression, but the length header is stripped from the wrapped resource files. Yet another possibly related format appears in the DSI game [https://www.mobygames.com/game/107/test-drive/ Test Drive] with the header "<tt>Pckd</tt>".<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5798Compression2024-01-18T14:28:57Z<p>Dstien: /* Barchard */ Identified Huffman method.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=2 colspan=2 | Barchard !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness !! Huffman !! BPE<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== Barchard ===<br />
Non-3d shape resource files uses another Distinctive Software in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''"Barchard"'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC BPE || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga Huffman || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga Huffman || <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt><br />
|-<br />
| Stunts Amiga BPE || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 BPE || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits !! Amiga !! PC98 !! Mickey<br />
|-<br />
| rowspan=2 | 0x4 Huffman coding<br />
| <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| rowspan=7 | 0x8 Byte pair encoding<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x45</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">101</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| rowspan=3 | 0xC Obfuscation<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| 0xD Store<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center | X<br />
|}<br />
<br />
==== 0x4 Huffman coding ====<br />
Similar to, but incompatible with the Huffman coding used in later EA games as method 0x6 and [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-huffman.htm documented by Martin Korth].<br />
<br />
==== 0x8 Byte pair encoding ====<br />
[https://en.wikipedia.org/wiki/Byte_pair_encoding Byte pair encoding] replaces frequently occurring byte pairs with a single byte that is not used elsewhere in the data. The process is repeated recursively until there are no more repeated byte pairs or available code bytes. Appears to be the same format as [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-bpe.htm documented by Martin Korth].<br />
<br />
==== 0xC Obfuscation ====<br />
Very simple data obfuscation scheme where each byte is subtracted from the previous. The process is reversed by adding running bytes as they are copied.<br />
<br />
==== 0xD Store ====<br />
Data is embedded without any transformations.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple byte-oriented [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format also found in earlier Amiga games from DSI. Compression ratio is inferior to Barchard's byte pair encoding. RPck may have been kept for performance reasons or deadline constraints.<br />
<br />
<span class="hlC">// Big endian byte ordering.</span><br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">char</span> magic<span class="hlB">[</span>4<span class="hlB">]</span> <span class="hlC">// "RPck" or "Rpck"</span><br />
<span class="hlP">uint32</span> uncompressed_size<br />
<span class="hlP">uint32</span> bytes_saved<br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
After the header comes a one-byte control code treated as a signed integer. If the value is negative, it is negated and this number of bytes is read and copied directly to the output. Since the maximum length is 128, another control code is needed if there are more than 128 consecutive bytes without repetition. If the control byte value is positive, the following byte is copied to the output and then duplicated the number of times specified in the control byte. This is repeated until <tt>uncompressed_size</tt> is reached or there is no more data in the source buffer.<br />
<br />
The game is also shipped with two files, ''stdapmin.psh'' and ''stdbaudi.psh'', which appears to be wrapped in another variant of this format. The header is "<tt>PPkc</tt>" [''sic.''] and the contents are stored without compression, but the length header is stripped from the wrapped resource files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [[#Barchard|Barchard]] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5783Compression2024-01-12T13:16:45Z<p>Dstien: /* RPck */ Format description.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | Barchard !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== Barchard ===<br />
Non-3d shape resource files uses another Distinctive Software in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''"Barchard"'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC BPE || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga Method 1 || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga Method 1 || <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt><br />
|-<br />
| Stunts Amiga BPE || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 BPE || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits !! Amiga !! PC98 !! Mickey<br />
|-<br />
| rowspan=2 | 0x4<br />
| <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| rowspan=7 | 0x8 Byte pair encoding<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x45</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">101</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| rowspan=3 | 0xC Obfuscation<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| 0xD Store<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center | X<br />
|}<br />
<br />
==== 0x8 - Byte pair encoding ====<br />
[https://en.wikipedia.org/wiki/Byte_pair_encoding Byte pair encoding] replaces frequently occurring byte pairs with a single byte that is not used elsewhere in the data. The process is repeated recursively until there are no more repeated byte pairs or available code bytes. Appears to be the same format as [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-bpe.htm documented by Martin Korth].<br />
<br />
==== 0xC Obfuscation ====<br />
Very simple data obfuscation scheme where each byte is subtracted from the previous. The process is reversed by adding running bytes as they are copied.<br />
<br />
==== 0xC Store ====<br />
Data is embedded without any transformations.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple byte-oriented [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format also found in earlier Amiga games from DSI. Compression ratio is inferior to Barchard's byte pair encoding. RPck may have been kept for performance reasons or deadline constraints.<br />
<br />
<span class="hlC">// Big endian byte ordering.</span><br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">char</span> magic<span class="hlB">[</span>4<span class="hlB">]</span> <span class="hlC">// "RPck" or "Rpck"</span><br />
<span class="hlP">uint32</span> uncompressed_size<br />
<span class="hlP">uint32</span> bytes_saved<br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
After the header comes a one-byte control code treated as a signed integer. If the value is negative, it is negated and this number of bytes is read and copied directly to the output. Since the maximum length is 128, another control code is needed if there are more than 128 consecutive bytes without repetition. If the control byte value is positive, the following byte is copied to the output and then duplicated the number of times specified in the control byte. This is repeated until <tt>uncompressed_size</tt> is reached or there is no more data in the source buffer.<br />
<br />
The game is also shipped with two files, ''stdapmin.psh'' and ''stdbaudi.psh'', which appears to be wrapped in another variant of this format. The header is "<tt>PPkc</tt>" and the contents are stored without compression, but the length header is stripped from the wrapped resource files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [[#Barchard|Barchard]] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5782Compression2024-01-11T17:40:58Z<p>Dstien: /* Barchard */ Store</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | Barchard !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== Barchard ===<br />
Non-3d shape resource files uses another Distinctive Software in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''"Barchard"'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC BPE || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga Method 1 || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga Method 1 || <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt><br />
|-<br />
| Stunts Amiga BPE || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 BPE || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits !! Amiga !! PC98 !! Mickey<br />
|-<br />
| rowspan=2 | 0x4<br />
| <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| rowspan=7 | 0x8 Byte pair encoding<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x45</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">101</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| rowspan=3 | 0xC Obfuscation<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| 0xD Store<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center | X<br />
|}<br />
<br />
==== 0x8 - Byte pair encoding ====<br />
[https://en.wikipedia.org/wiki/Byte_pair_encoding Byte pair encoding] replaces frequently occurring byte pairs with a single byte that is not used elsewhere in the data. The process is repeated recursively until there are no more repeated byte pairs or available code bytes. Appears to be the same format as [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-bpe.htm documented by Martin Korth].<br />
<br />
==== 0xC Obfuscation ====<br />
Very simple data obfuscation scheme where each byte is subtracted from the previous. The process is reversed by adding running bytes as they are copied.<br />
<br />
==== 0xC Store ====<br />
Data is embedded without any transformations.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format found in some Amiga file archiving software. Compression ratio is inferior to RefPack, but the code is simpler and faster, which may explain why it was chosen for these files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [[#Barchard|Barchard]] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5781Compression2024-01-11T17:22:47Z<p>Dstien: /* Barchard */ Identified obfuscation method.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | Barchard !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== Barchard ===<br />
Non-3d shape resource files uses another Distinctive Software in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''"Barchard"'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC BPE || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga Method 1 || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga Method 1 || <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt><br />
|-<br />
| Stunts Amiga BPE || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 BPE || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits !! Amiga !! PC98 !! Mickey<br />
|-<br />
| rowspan=2 | 0x4<br />
| <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| rowspan=7 | 0x8 Byte pair encoding<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x45</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">101</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| rowspan=3 | 0xC Obfuscation<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| 0xD<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center | X<br />
|}<br />
<br />
==== 0x8 - Byte pair encoding ====<br />
[https://en.wikipedia.org/wiki/Byte_pair_encoding Byte pair encoding] replaces frequently occurring byte pairs with a single byte that is not used elsewhere in the data. The process is repeated recursively until there are no more repeated byte pairs or available code bytes. Appears to be the same format as [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods-bpe.htm documented by Martin Korth].<br />
<br />
==== 0xC Obfuscation ====<br />
Very simple data obfuscation scheme where each byte is subtracted from the previous. The process is reversed by adding running bytes as they are copied.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format found in some Amiga file archiving software. Compression ratio is inferior to RefPack, but the code is simpler and faster, which may explain why it was chosen for these files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [[#Barchard|Barchard]] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5780Compression2024-01-11T16:39:03Z<p>Dstien: /* Barchard */ Methods recognised by Amiga port</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | Barchard !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== Barchard ===<br />
Non-3d shape resource files uses another Distinctive Software in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''"Barchard"'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC BPE || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga Method 1 || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga BPE || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 BPE || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits !! Amiga !! PC98 !! Mickey<br />
|-<br />
| rowspan=2 | Method 1<br />
| <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| <tt>0x27</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">111</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | <br />
|-<br />
| rowspan=7 | [https://en.wikipedia.org/wiki/Byte_pair_encoding Byte pair encoding]<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x45</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">101</span></tt> || style=text-align:center | || style=text-align:center | || style=text-align:center | X<br />
|-<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt> || style=text-align:center | || style=text-align:center | X || style=text-align:center |<br />
|-<br />
| rowspan=3 | Method 3<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
| Method 4<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt> || style=text-align:center | X || style=text-align:center | X || style=text-align:center | X<br />
|}<br />
<br />
A strong hypothesis suggests that the compression methods found here are related to the EA formats from PSX games [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods.htm documented by Martin Korth]. Further analysis is required to verify this.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format found in some Amiga file archiving software. Compression ratio is inferior to RefPack, but the code is simpler and faster, which may explain why it was chosen for these files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [[#Barchard|Barchard]] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5769Compression2024-01-09T17:11:32Z<p>Dstien: /* PC98 */ s/RefPack/Barchard/</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | Barchard !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== Barchard ===<br />
Non-3d shape resource files uses another Distinctive Software in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''"Barchard"'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga type 1 || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga type 2 || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files. This analysis does not include the Amiga port, as this code has not been dissected yet.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits<br />
|-<br />
| rowspan=4 | Mickey type 1<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt><br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt><br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| rowspan=2 | Stunts type 1<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt><br />
|-<br />
| rowspan=3 | Stunts PC98 and Mickey type 2<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt><br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt><br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts PC98 and Mickey type 3<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt><br />
|}<br />
<br />
A strong hypothesis suggests that the compression methods found here are related to the EA formats from PSX games [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods.htm documented by Martin Korth]. Further analysis is required to verify this.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format found in some Amiga file archiving software. Compression ratio is inferior to RefPack, but the code is simpler and faster, which may explain why it was chosen for these files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [[#Barchard|Barchard]] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5768Compression2024-01-09T17:00:19Z<p>Dstien: Replaced disproved RefPack speculation with updated research.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | Barchard !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== Barchard ===<br />
Non-3d shape resource files uses another Distinctive Software in-house format that is characterized by the identification byte <tt>0xFB</tt>, assumed to be the initials of its author, [https://www.mobygames.com/person/7186/frank-barchard/ Frank Barchard]. This format supports a suite of different compression methods and it evolved through the 90's and early 2000's as a part of EA's internal engine libraries. Whereas later games tended to use the [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based [https://github.com/lingeringwillx/Refpack-QFS-Resources RefPack] algorithm, the Stunts ports uses other methods. We will therefore refer to these compressions as ''"Barchard"'' to distinguish them from the ubiquitous RefPack.<br />
<br />
This is the currently assumed header structure:<br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">uint8</span> method_flags : 3<br />
<span class="hlP">uint8</span> method_type : 4<br />
<span class="hlP">uint8</span> 32bit_length : 1 <span class="hlC">// Not used by Stunts</span><br />
<span class="hlP">uint8</span> magic <span class="hlC">// Always 0xFB</span><br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<br />
<span class="hlC">// Possibly more fields if indicated by method_flags</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
Below are the values of the first byte in the shipped files. Values from the DOS version of [https://www.mobygames.com/game/56474/mickeys-abcs-a-day-at-the-fair/ Mickey's ABC's: A Day at the Fair] are included, as this may be the first public incarnation of Barchard compression. The bitfield suspected to be the method is highlighted in red, the method flags in green.<br />
<br />
{| class="wikitable"<br />
! Game !! Hex !! Bits<br />
|-<br />
| Mickey's ABC || <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts Amiga type 1 || <tt>0x26</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">0100</span><span style="color:green">110</span></tt><br />
|-<br />
| Stunts Amiga type 2 || <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| Stunts PC98 || <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|}<br />
<br />
The game code appears to support several other methods that are not used by the shipped files. This analysis does not include the Amiga port, as this code has not been dissected yet.<br />
<br />
{| class="wikitable"<br />
! Method !! Hex !! Bits<br />
|-<br />
| rowspan=4 | Mickey type 1<br />
| <tt>0x40</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">000</span></tt><br />
|-<br />
| <tt>0x41</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">001</span></tt><br />
|-<br />
| <tt>0x42</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">010</span></tt><br />
|-<br />
| <tt>0x44</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">100</span></tt><br />
|-<br />
| rowspan=2 | Stunts type 1<br />
| <tt>0x46</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">110</span></tt><br />
|-<br />
| <tt>0x47</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1000</span><span style="color:green">111</span></tt><br />
|-<br />
| rowspan=3 | Stunts PC98 and Mickey type 2<br />
| <tt>0x60</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">000</span></tt><br />
|-<br />
| <tt>0x62</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">010</span></tt><br />
|-<br />
| <tt>0x66</tt> || <tt><span style="color:lightgray">0</span><span style="color:red">1100</span><span style="color:green">100</span></tt><br />
|-<br />
| Stunts PC98 and Mickey type 3<br />
| <tt>0x6B || <tt><span style="color:lightgray">0</span><span style="color:red">1101</span><span style="color:green">011</span></tt><br />
|}<br />
<br />
A strong hypothesis suggests that the compression methods found here are related to the EA formats from PSX games [https://problemkaputt.de/psxspx-cdrom-file-compression-ea-methods.htm documented by Martin Korth]. Further analysis is required to verify this.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format found in some Amiga file archiving software. Compression ratio is inferior to RefPack, but the code is simpler and faster, which may explain why it was chosen for these files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [http://wiki.niotso.org/RefPack RefPack] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5633Compression2023-06-29T10:29:36Z<p>Dstien: /* Run-length encoding */ Typos.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | RefPack !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run-length encoding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== RefPack ===<br />
Non-3d shape resource files uses the Electronic Arts in-house [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based compression format [http://wiki.niotso.org/RefPack RefPack]. This may be one of the first known uses of RefPack which since became part of EA's internal engine libraries and has been used in many games through the 90's and early 2000's. The bit stream format is fully documented and has multiple implementations available, but the header flags have either changed, or the unofficial implementations make incorrect assumptions about them, causing the decompressors to wrongfully assume that the 4D Sports Driving files are not compressed due to not having the <tt>0x01</tt> flag set.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format found in some Amiga file archiving software. Compression ratio is inferior to RefPack, but the code is simpler and faster, which may explain why it was chosen for these files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [http://wiki.niotso.org/RefPack RefPack] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5613Compression2023-06-25T13:45:09Z<p>Dstien: Cover all platforms.</p>
<hr />
<div>Stunts and its ports uses multiple compression formats for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. <br />
<br />
== Formats by game version ==<br />
{| class="wikitable"<br />
! rowspan=3 colspan=3 | Game version !! colspan=4 | Stunts packing !! rowspan=3 | RefPack !! rowspan=3 | RPck<br />
|-<br />
! rowspan=2 | RLE !! colspan=3 | Huffman<br />
|-<br />
! Supported !! Prefix table !! Code endianness<br />
|-<br />
! rowspan=4 style=text-align:left | MS DOS !! rowspan=2 | BB 1.0 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || || Big || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! rowspan=2 | BB 1.1/MS 1.1 !! style=text-align:left | Game<br />
| style=text-align:center | X || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! style=text-align:left | Loader<br />
| || style=text-align:center | X || style=text-align:center | X || Little || ||<br />
|-<br />
! colspan=3 style=text-align:left | Amiga<br />
| || || || || style=text-align:center | X || style=text-align:center | X<br />
|-<br />
! colspan=3 style=text-align:left | PC98<br />
| || || || || style=text-align:center | X ||<br />
|-<br />
! colspan=3 style=text-align:left | FM Towns<br />
| || || || || ||<br />
|}<br />
<br />
== MS DOS ==<br />
The original release of Stunts uses a custom data compression format not found in the ports to other platforms. The code may have been hand-crafted for 16-bit x86 since other options were favoured in the later ports.<br />
<br />
The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
=== File header ===<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
=== Run length coding ===<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> unknown <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
==== RLE decoding optimisation ====<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
=== Huffman coding ===<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
==== Delta coding ====<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
==== Huffman decoding optimisations ====<br />
===== Prefix table =====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
===== Offset table =====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
==== Version differences ====<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
== Amiga ==<br />
The Amiga port uses two unrelated compression formats.<br />
<br />
=== RefPack ===<br />
Non-3d shape resource files uses the Electronic Arts in-house [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski LZSS]-based compression format [http://wiki.niotso.org/RefPack RefPack]. This may be one of the first known uses of RefPack which since became part of EA's internal engine libraries and has been used in many games through the 90's and early 2000's. The bit stream format is fully documented and has multiple implementations available, but the header flags have either changed, or the unofficial implementations make incorrect assumptions about them, causing the decompressors to wrongfully assume that the 4D Sports Driving files are not compressed due to not having the <tt>0x01</tt> flag set.<br />
<br />
=== RPck ===<br />
3-d shapes are compressed with RPck, a simple [https://en.wikipedia.org/wiki/Run-length_encoding RLE]-based format found in some Amiga file archiving software. Compression ratio is inferior to RefPack, but the code is simpler and faster, which may explain why it was chosen for these files.<br />
<br />
== PC98 ==<br />
The PC98 port of the game uses [http://wiki.niotso.org/RefPack RefPack] to compress some of the bitmap image resource files. See the Amiga section for more details.<br />
<br />
== FM Towns ==<br />
The FM Towns and FM Towns Marty ports of the game were distributed on CD-ROM with ample storage and does not apply any compression to the game resource files.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5611Compression2023-06-22T07:49:13Z<p>Dstien: Typos.</p>
<hr />
<div>Stunts uses a custom data compression format for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
== File header ==<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
== Run length coding ==<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> unknown <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint32</span> compressed_size : 24<br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
=== RLE decoding optimisation ===<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
== Huffman coding ==<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
=== Delta coding ===<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
=== Huffman decoding optimisations ===<br />
==== Prefix table ====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
==== Offset table ====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
=== Version differences ===<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5590Compression2023-06-16T08:45:36Z<p>Dstien: /* Run length coding */ Sequence escape code.</p>
<hr />
<div>Stunts uses a custom data compression format for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
== File header ==<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
== Run length coding ==<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> unknown <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[1]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. This allows the second escape code reserved for sequences to serve as a no-op without the two passes interfering. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
=== RLE decoding optimisation ===<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
== Huffman coding ==<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create a leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
=== Delta coding ===<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
=== Huffman decoding optimisations ===<br />
==== Prefix table ====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
==== Offset table ====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
=== Version differences ===<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5589Compression2023-06-16T04:56:11Z<p>Dstien: RLE intro, article category, typo fixes.</p>
<hr />
<div>Stunts uses a custom data compression format for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
== File header ==<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
== Run length coding ==<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> unknown <span class="hlC">// Always 0x00, value is ignored by the game</span><br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
RLE is used to reduce the length of consecutively repeated bytes by using an escape code followed by a counter to signify how many times the next byte should be repeated. It is particularly useful for compressing images, as large areas with a single colour would be represented by many consecutive identical bytes.<br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[0]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
=== RLE decoding optimisation ===<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
== Huffman coding ==<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create a leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
=== Delta coding ===<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
=== Huffman decoding optimisations ===<br />
==== Prefix table ====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits wide. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
==== Offset table ====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
=== Version differences ===<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use a prefix table, and the bit-stream orientation was likely changed with the introduction of this optimisation.<br />
<br />
[[Category:Internals]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Compression&diff=5588Compression2023-06-14T13:16:18Z<p>Dstien: Created page with "Stunts uses a custom data compression format for code and resource files to save disk space and, more importantly, the number of floppy disks used to..."</p>
<hr />
<div>Stunts uses a custom data compression format for code and [[Resource_file_format|resource files]] to save disk space and, more importantly, the number of floppy disks used to distribute the game. The data format supports both [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoding] (RLE) and [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding]. They can be combined in multiple passes. The data format and the decompression code don't require any particular order or combination of algorithms. Every compressed file shipped with the game use Huffman coding, and when combined with RLE, the RLE pass is applied before Huffman.<br />
<br />
== File header ==<br />
<br />
<span class="hlP">enum</span> CompressionType <span class="hlB">{</span><br />
RLE = 1<br />
Huffman = 2<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> Header <span class="hlB">{</span><br />
<span class="hlP">union</span> <span class="hlB">{</span><br />
<span class="hlP">uint8</span> passes : 7<br />
<span class="hlP">uint8</span> compression_type : 7<br />
<span class="hlB">}</span><br />
<span class="hlP">uint8</span> multi_pass : 1<br />
<span class="hlP">uint32</span> uncompressed_size : 24<br />
<span class="hlB">}</span><br />
<br />
<br />
If the most significant bit of the first byte of the file is set, this is a multi-pass file and the remaining 7 bits are the number of passes to be processed recursively. If the <tt>multi_pass</tt> flag is not set, we are only doing a single pass and the first byte is the compression type. The next three bytes make up the uncompressed size. If the <tt>multi_pass</tt> flag was set, this is the final uncompressed size. When the <tt>multi_pass</tt> flag is not set, this is the uncompressed size of the current pass. The remaining data is processed recursively. The <tt>compression_type</tt> field decides how it is decoded.<br />
<br />
== Run length coding ==<br />
<br />
<span class="hlP">struct</span> RLE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> unknown<br />
<span class="hlP">uint8</span> escape_length : 7<br />
<span class="hlP">uint8</span> no_sequence : 1<br />
<span class="hlP">uint8</span> escape_codes<span class="hlB">[</span>escape_length<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> data<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
The RLE stage can itself have two passes if <tt>no_sequence</tt> is not set. The first pass will then expand sequences of bytes in the data. <tt>escape_codes[0]</tt> will mark the beginning and the end of a byte sequence. When the escape code is encountered in the data, the following bytes are considered a sequence until the escape code is hit again. After the end-marking escape code, a one byte length counter tells how many times the preceding byte sequence should be repeated in the output buffer. Because the escape code cannot itself be escaped, sequential byte runs can only be applied in files that have unused byte values to use as the first escape code.<br />
<br />
The main RLE pass is a traditional expansion of single-byte runs, but with a twist that allows for multiple types of escape codes. The escape code's position in the header's escape code list affects its properties. When the first escape code is encountered in the source buffer, the following byte has the number of repetitions, and the next byte will be copied that many times to the output buffer. When the third escape code is encountered, the number of repetitions is stored in the following ''two'' bytes as a 16-bit integer. Then the following byte is copied that many times. All other escape codes use its position in the escape code list as the number of repetitions, and have no additional counter bytes before the data byte to be repeated. Escape codes can themselves be escaped in single-byte runs by having them expanded to only one copy.<br />
<br />
All repetition counters have an off-by-one surplus, as the data byte itself counts as the first copy. For optimal compression, escape codes should be chosen from byte values that occur least frequently, or not at all, in the source data.<br />
<br />
=== RLE decoding optimisation ===<br />
Escape codes are put in an <tt>escape[256]</tt> array, where the code's byte value is the index and the escape code's position is the entry's value. This array is used to test incoming bytes for escape codes. Raw bytes will have the value 0, while other values corresponds to the escape code's property. This optimisation makes the decoding run O(1), as opposed to O(''n''), where ''n'' is the number of escape codes.<br />
<br />
== Huffman coding ==<br />
<br />
<span class="hlP">struct</span> Huffman <span class="hlB">{</span><br />
<span class="hlP">uint8</span> tree_levels : 7<br />
<span class="hlP">uint8</span> delta_coding : 1<br />
<span class="hlP">uint8</span> symbols_per_level<span class="hlB">[</span>tree_levels<span class="hlB">]</span><br />
<span class="hlP">uint8</span> alphabet<span class="hlB">[</span><span class="hlP">SUM</span><span class="hlB">(</span>symbols_per_level<span class="hlB">)</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint16</span> codes : var <span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<br />
Huffman coding uses a binary tree to store data. When Huffman codes are read, each bit tells which branch to take when traversing the tree. If a leaf node is hit, we have found the code's symbol and can proceed with the next code. Frequently used symbols have shorter paths and thus takes up fewer bits in the source file.<br />
<br />
The tree is stored by having two lists, one with symbols per level, and one with the alphabet. The alphabet is every possible symbol in the order they appear in the tree. The tree is built by going through each <tt>symbols_per_level</tt>. If there are symbols at the current level, consume them from <tt>alphabet</tt> and create a leaf nodes. If there are no symbols, and there still are more levels to create, proceed to create left and right children nodes for the next level.<br />
<br />
The remaining data is the Huffman codes. Bit by bit is read to find leaf nodes in the Huffman tree whose symbols are appended to the output buffer. This is repeated until the output buffer has reached <tt>uncompressed_size</tt>.<br />
<br />
The maximum Huffman tree height is 16. While the data format allows for up to 127 levels, Stunts' decompression function uses arrays with a fixed capacity of 16 for its level offset table.<br />
<br />
=== Delta coding ===<br />
If the flag for [https://en.wikipedia.org/wiki/Delta_encoding delta coding] is set, each symbol is treated as the difference from the previous output byte instead of an independent final value. The last byte written to the output buffer is remembered and added to the next expanded symbol. While regular Huffman coding assigns shorter codes to frequently occurring values, this delta variant assigns shorter codes to differences that occurs frequently. This feature is not used by any shipped files, but the code is present in all versions that implements Huffman decoding. One can speculate that delta coding was outperformed by RLE combined with regular Huffman coding, making delta coding unnecessary.<br />
<br />
=== Huffman decoding optimisations ===<br />
==== Prefix table ====<br />
With Huffman codes being paths in a binary tree, they have the property of being prefix-free, meaning that one leaf node's code cannot be the prefix of another node's code. This allows for a decoding optimisation technique known as ''prefix tables'' or ''Huffman tables''. By creating arrays of symbols and code widths where the indices are the Huffman codes, the codes can be looked up directly without traversing the tree. Every array index for non-leaf nodes between two leaf node entries are filled with data for the preceding leaf node. This way there's no need to filter out bits that belong to the next Huffman code, at the expense of common symbols taking up multiple entries in the lookup table during decompression.<br />
<br />
Stunts utilises this optimisation for Huffman codes that are up to 8 bits long. The first byte of the code is checked in the <tt>widths[256]</tt> array. If the code's width is 8 bits or less, the same code is looked up in the <tt>symbols[256]</tt> array and written to the output buffer. To find the start of the next Huffman code, the source buffer is advanced by the code's bit width found in the <tt>widths</tt> array.<br />
<br />
==== Offset table ====<br />
As Stunts limits the prefix tables to 8 bit wide Huffman codes to save RAM, another novel optimisation is applied for codes that exceeds 8 bits. Prefixes for longer codes have the value <tt>0x40</tt> in the <tt>widths</tt> array, indicating that the current code is a prefix that needs further expansion. For this purpose Stunts uses two additional helper arrays: <tt>total_codes[tree_levels]</tt>, which has the total number of leaf nodes that exists in the tree up to each level, and <tt>code_offsets[tree_levels]</tt>, which for each level has a value that can be added to a code with the same level in order to get its index in the alphabet. This works because the codes are arranged [https://en.wikipedia.org/wiki/Canonical_Huffman_code canonically]. As a code's bit width corresponds to the code's level in the Huffman tree, the width can be used to compare the current code with the level's total by getting <tt>total_codes[current_width]</tt> for each extra bit read. If the code is smaller than the total number of codes encountered, it is a leaf node, and we get the symbol by adding the level's code offset to the code with <tt>alphabet[code + code_offsets[width]]</tt>. This is more laborious than the use of prefix tables for direct lookup, but it only applies to codes that are occurring less frequently in the input file.<br />
<br />
=== Version differences ===<br />
The Huffman decompression in the game code of Stunts 1.0 differs from the one in its LOAD.EXE and later versions of the game. The Huffman codes are written with the least significant bit first, as opposed to the other versions that has the codes written with the opposite orientation. The game code of Stunts 1.0 also does not use the prefix tables, and the bit-stream orientation was likely changed with the introduction of this optimisation.</div>Dstienhttps://wiki.stunts.hu/index.php?title=Opponent_files&diff=1771Opponent files2010-02-20T23:55:04Z<p>Dstien: /* Opponent animations */ Frame index list is NULL-terminated.</p>
<hr />
<div>Data corresponding to the Stunts [[opponents]] is stored by a number of [[Resource file format|resource files]], namely sdosel.pvs and the multiple opp?win.pvs, opp?lose.pvs and opp?.pre. As denoted by their extensions, the opp?.pre files store control parameters and text data, while the .pvs files contain bitmaps. A vanilla installation of Stunts 1.1 uses compressed opp?.pre files, while Stunts 1.0 has them uncompressed, as opp?.res. The contents of each file will be described below, organized by function of the resources.<br />
<br />
==Opponent selection==<br />
<br />
All the images used for composing the opponent selection menu are within ''sdosel.pvs''. Bitmap resources '''opp0''' to '''opp6''' are opponent portraits (opp0 is actually the chronometer for the time trial option); '''scrn''' and the auxiliary overlay '''clip''' form the background. Text for the opponent profiles is sourced from text resources in the ''opp?.pre'' (there are six of these, one for each opponent).<br />
<br />
==Opponent animations==<br />
<br />
{{sectstub}}<br />
<br />
Win/lose animations are made from individual bitmaps in ''opp?win.pvs'' or ''opp?lose.pvs''. The bitmap resources are named '''op01''' to '''op08''' - the actual number of frames within a file varies from 3 to 8. The animations are controlled through simple, unstructured resources in '''opp?.pre''' named '''winn''' and '''lose'''. Each byte in these NULL-terminated resources is a numerical index to the op01 ... op08 bitmaps, and the overall sequence is the succession of frames.<br />
<br />
==Opponent performance==<br />
<br />
{{sectstub}}<br />
<br />
The primary adjustable parameters which determine opponent skills are maximum speeds for different track elements. These parameters are in an unstructured resource within ''opp?.pre'' called '''sped'''. sped is 15 bytes long for Stunts 1.0 and 16 bytes long for 1.1 . Each byte corresponds to the speed in mph for a track element, as described below:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Byte (in 1.1) !! Track element !! Observations<br />
|-<br />
| 1 - 3 || paved, dirt and icy road || respectively<br />
|-<br />
| 4 - 6 || paved, dirt and icy small corner || respectively<br />
|-<br />
| 7 - 9 || paved, dirt and icy large corner || respectively<br />
|-<br />
| 10 || banked corner || ''absent in 1.0''<br />
|-<br />
| 11 || bridge ||<br />
|-<br />
| 12 || slalom ||<br />
|-<br />
| 13 || cork u/d ||<br />
|-<br />
| 14 || chicane ||<br />
|-<br />
| 15 || loop ||<br />
|-<br />
| 16 || cork l/r ||<br />
|-<br />
|}<br />
<br />
[[Opponent Blaster]], a [[Mark Nailwood]] program, allows for edition of sped parameter from Stunts 1.0 opp?.res files. The program can't open compressed opp?.pre files from 1.1 without prior unpacking with [[stunpack]]. Even after unpacking, the addition of the banked corner parameter and the reordering of the resource list in the 1.1 files means Opponent Blaster is unable to parse them correctly. In fact, it turns out that 1.0 and 1.1 opponent data files are not interchangeable at all.<br />
<br />
In addition to sped, opp?.pre also contains '''path''', a much larger (186 bytes) numerical data resource which function is not yet understood. <br />
<br />
[[Category:Modding]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Category:Driving&diff=1027Category:Driving2008-11-11T12:59:33Z<p>Dstien: Reverted edits by 78.46.197.81 (Talk); changed back to last version by Zaqrack</p>
<hr />
<div>Everything related to driving</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=1007Resource file format2008-10-18T22:33:27Z<p>Dstien: /* 3d shapes */ Corrections according to latest discoveries.</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple ''resources'', blocks of data that may be of various types - text, bitmaps, sounds, etc. Resources are uniquely identified within each file solely by a 4-byte name. A resource container file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span class="hlC">// Header</span><br />
<span class="hlP">uint32</span> fileLength<br />
<span class="hlP">uint16</span> numResources<br />
<br />
<span class="hlC">// Table of contents</span><br />
<span class="hlP">char</span> ids<span class="hlB">[</span>numResources<span class="hlB">][</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint32</span> offsets<span class="hlB">[</span>numResources<span class="hlB">]</span><br />
<br />
<span class="hlC">// Resource data</span><br />
<span class="hlP">char</span> data<span class="hlB">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span class="hlP">uint16</span> width<br />
<span class="hlP">uint16</span> height<br />
<span class="hlP">uint16</span> unknown1<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint8</span> unknown2<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> image<span class="hlB">[</span>width <span class="hlB">*</span> height<span class="hlB">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' internal memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression]. Images with pixel data stored as continuous horizontal lines has <tt>unknown2</tt> set to <code>{ 0x1, 0x2, 0x4, 0x8 }</code>.<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
Shapes are composed of a vertex list and a list of primitives. Primitives are basic shapes that can have different types, such as polygons or wheels. Depending on the type it contains a number of indices into the vertex list needed to draw the shape, color variations and some rendering hints. Stunts' coordinate system use 16-bit signed integers, making the resolution relative to the scale of the model. Shapes presented in the car selection screen are more detailed than in-game shapes, thus requiring larger scaling. By comparing the car shapes to their real-life originals 1 meter in-game corresponds to 20 units, making each track tile roughly 50 meters wide.<br />
<br />
Due to the counter header fields being stored in single bytes, the total amount of vertices and primitives are limited to 255 per shape.<br />
<br />
'''Main strcture'''<br />
<span class="hlP">uint8</span> numVertices<br />
<span class="hlP">uint8</span> numPrimitives<br />
<span class="hlP">uint8</span> numPaintJobs<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always == 0</span><br />
<br />
VERTEX vertices<span class="hlB">[</span>numVertices<span class="hlB">]</span><br />
<span class="hlP">uint32</span> cullHorizontal<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
<span class="hlP">uint32</span> cullVertical<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
PRIMITIVE primitives<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> terminate<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// 1-3 NULL-bytes for data alignment</span><br />
<br />
'''Additional structures'''<br />
<span class="hlP">struct</span> VERTEX <span class="hlB">{</span><br />
<span class="hlP">int16</span> x<br />
<span class="hlP">int16</span> y<br />
<span class="hlP">int16</span> z<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> PRIMITIVE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> type<br />
<span class="hlP">uint8</span> flags<br />
<span class="hlP">uint8</span> materials<span class="hlB">[</span>numPaintJobs<span class="hlB">]</span><br />
<span class="hlP">uint8</span> indices<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// Size depends on type.</span><br />
<span class="hlB">}</span><br />
<br />
'''Primitive types'''<br />
{| class="wikitable"<br />
! Primitive type !! Vertex indices needed !! Description<br />
|-<br />
| 1 || 1 || Particle, 1 pixel<br />
|-<br />
| 2 || 2 || Line segment, 1 pixel width<br />
|-<br />
| 3–10 || 3–10 || Polygon, ''n'' sides<br />
|-<br />
| 11 || 2 || Sphere (center + ~(radius / 2)<br />
|-<br />
| 12 || 6 || Wheel<br />
|-<br />
| * || 0 || Ignored<br />
|}<br />
<br />
'''Primitive flags'''<br />
{| class="wikitable"<br />
! Flag !! Name<br />
|-<br />
| <tt>0x01</tt> || Two-sided<br />
|-<br />
| <tt>0x02</tt> || Z-Bias<br />
|-<br />
| * || Ignored<br />
|}<br />
<br />
'''Culling data masks'''<br />
{| class="wikitable"<br />
! Flag !! Description<br />
|-<br />
| <tt>0xFFFE0000</tt> || Angle ranges, positive direction<br />
|-<br />
| <tt>0x0001FFFC</tt> || Angle ranges, negative direction<br />
|-<br />
| <tt>0x00000001</tt> || Unknown flag 1<br />
|-<br />
| <tt>0x00000002</tt> || Unknown flag 2<br />
|}<br />
<br />
For car body and track element shapes the first eight vertices are reserved for the corner vertices of the shape's bound box, used to cull entire shapes located outside the view frustum.<br />
<br />
[[Image:Wheel_Primitive_Anatomy.png|200px|right|thumb|Anatomy of a wheel shape primitive.]]<br />
The first three vertices in a wheel primitive marks the center, tire radius and rim radius for the inner wheel-half facing the vehicle. The last three vertices does the same, in the same order, for the outer half of the wheel. Directions may not matter, the vertex locations are used to measure distances. This rule applies to the sphere primitive as well.<br />
<br />
Wheel transformations are performed on fixed vertex positions. Since the first eight vertices of <tt>car[0-2]</tt> shapes are occupied by the bound box, vertices 9-14 and 15-20 are front wheels. Misplaced wheel vertices will lead to corrupted shape rendering.<br />
<br />
The <tt>flags</tt> in the <tt>PRIMITIVE</tt> structure are used for two-sided polygons (disable [http://en.wikipedia.org/wiki/Back-face_culling back-face culling]) and to enable Z-bias in order to resolve [http://en.wikipedia.org/wiki/Z-fighting Z-fighting].<br />
<br />
[[Shape materials|Materials]] are indices into a permanent, internal game structure and are assigned per-primitive. Cars can have multiple paint jobs, every primitive in the shape must set a material for each color scheme.<br />
<br />
Each primitive has two 32-bit culling data fields to determine visibility. A culling data field holds angular visibility in positive and negative direction using 15 bits each. One bit corresponds to 1/15th of a full circle and the bits can be set in any combination. The two least significant bits are reserved for two currently unknown flags.<br />
<br />
A shape resource must be terminated with NULL-bytes. The number of bytes needed is not known, but padding three NULL-bytes has proven to work regardless of resource size or byte alignment. Failing to meet this requirement will lead to obscure rendering artifacts.<br />
<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
Numerical car*.res parameters are stored in a 776 bytes sized resource identified as ''simd''. Most data in simd is stored as signed 16-bit integers. Noteworthy exceptions include number of gears, gear ratios, torque curve data and bitmap coordinates for dashboard instruments - which are unsigned 8-bit integers. Organization and function of the parameters are outside the scope of this article; the reader should consult the main article on the topic for further information. <br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=843Resource file format2008-06-28T17:23:30Z<p>Dstien: /* 3d shapes */ Unit scale</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple ''resources'', blocks of data that may be of various types - text, bitmaps, sounds, etc. Resources are uniquely identified within each file solely by a 4-byte name. A resource container file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span class="hlC">// Header</span><br />
<span class="hlP">uint32</span> fileLength<br />
<span class="hlP">uint16</span> numResources<br />
<br />
<span class="hlC">// Table of contents</span><br />
<span class="hlP">char</span> ids<span class="hlB">[</span>numResources<span class="hlB">][</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint32</span> offsets<span class="hlB">[</span>numResources<span class="hlB">]</span><br />
<br />
<span class="hlC">// Resource data</span><br />
<span class="hlP">char</span> data<span class="hlB">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span class="hlP">uint16</span> width<br />
<span class="hlP">uint16</span> height<br />
<span class="hlP">uint16</span> unknown1<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint8</span> unknown2<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> image<span class="hlB">[</span>width <span class="hlB">*</span> height<span class="hlB">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' internal memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression]. Images with pixel data stored as continuous horizontal lines has <tt>unknown2</tt> set to <code>{ 0x1, 0x2, 0x4, 0x8 }</code>.<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
Shapes are composed of a vertex list and a list of primitives. Primitives are basic shapes that can have different types, such as polygons or wheels. Depending on the type it contains a number of indices into the vertex list needed to draw the shape, color variations and some rendering hints. Stunts' coordinate system use 16-bit signed integers, making the resolution relative to the scale of the model. Shapes presented in the car selection screen are more detailed than in-game shapes, thus requiring larger scaling. By comparing the car shapes to their real-life originals 1 meter in-game corresponds to 20 units, making each track tile roughly 50 meters wide.<br />
<br />
Due to the counter header fields being stored in single bytes, the total amount of vertices and primitives are limited to 255 per shape.<br />
<br />
'''Main strcture'''<br />
<span class="hlP">uint8</span> numVertices<br />
<span class="hlP">uint8</span> numPrimitives<br />
<span class="hlP">uint8</span> numPaintJobs<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always == 0</span><br />
<br />
VERTEX vertices<span class="hlB">[</span>numVertices<span class="hlB">]</span><br />
UNKNOWN unknowns<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
PRIMITIVE primitives<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> terminate<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// One or two NULL-bytes to make resource size divisible by 2.</span><br />
<br />
'''Additional structures'''<br />
<span class="hlP">struct</span> VERTEX <span class="hlB">{</span><br />
<span class="hlP">int16</span> x<br />
<span class="hlP">int16</span> y<br />
<span class="hlP">int16</span> z<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> UNKNOWN <span class="hlB">{</span><br />
<span class="hlP">int8</span> data<span class="hlB">[</span><span class="hlN">8</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> PRIMITIVE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> type<br />
<span class="hlP">uint8</span> depthIndex<br />
<span class="hlP">uint8</span> materials<span class="hlB">[</span>numPaintJobs<span class="hlB">]</span><br />
<span class="hlP">uint8</span> indices<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// Size depends on type.</span><br />
<span class="hlB">}</span><br />
<br />
'''Primitive types'''<br />
{| class="wikitable"<br />
! Primitive type !! Vertex indices needed !! Description<br />
|-<br />
| 1 || 1 || Particle, 1 pixel<br />
|-<br />
| 2 || 2 || Line segment, 1 pixel width<br />
|-<br />
| 3–10 || 3–10 || Polygon, ''n'' sides<br />
|-<br />
| 11 || 2 || Sphere (center + ~(radius / 2)<br />
|-<br />
| 12 || 6 || Wheel<br />
|-<br />
| * || 0 || Ignored<br />
|}<br />
<br />
For car body and track element shapes the first eight vertices are reserved for the corner vertices of the shape's bound box, used to cull entire shapes located outside the view frustum.<br />
<br />
[[Image:Wheel_Primitive_Anatomy.png|200px|right|thumb|Anatomy of a wheel shape primitive.]]<br />
The first three vertices in a wheel primitive marks the center, tire radius and rim radius for the inner wheel-half facing the vehicle. The last three vertices does the same, in the same order, for the outer half of the wheel. Directions does not matter, the vertex locations are only used to measure distances. This rule applies to the sphere primitive as well.<br />
<br />
Wheel transformations are performed on fixed vertex positions. Since the first eight vertices of <tt>car[0-2]</tt> shapes are occupied by the bound box, vertices 9-14 and 15-20 are front wheels. Misplaced wheel vertices will lead to corrupted shape rendering.<br />
<br />
The value <tt>depthIndex</tt> in the <tt>PRIMITIVE</tt> structure is used to override the game's depth clipping in order to avoid flickering when several primitives are being drawn at the exact same depth. Higher value gives the primitive higher precedence.<br />
<br />
[[Shape materials|Materials]] are indices into a permanent, internal game structure and are assigned per-primitive. Cars can have multiple paint jobs, every primitive in the shape must set a material for each color scheme.<br />
<br />
Experimentation has revealed that <tt>UNKNOWN</tt> data at least partially controls occlusion culling on primitive level. How, and exactly which parts of this structure does what has yet to be understood.<br />
<br />
A shape resource must be terminated with a NULL-byte and the size must be divisible by two, hence two NULL-bytes are needed to terminate and pad resources with an even number of bytes. Failing to meet this requirement will lead to obscure rendering artifacts.<br />
<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
Numerical car*.res parameters are stored in a 776 bytes sized resource identified as ''simd''. Most data in simd is stored as signed 16-bit integers. Noteworthy exceptions include number of gears, gear ratios, torque curve data and bitmap coordinates for dashboard instruments - which are unsigned 8-bit integers. Organization and function of the parameters are outside the scope of this article; the reader should consult the main article on the topic for further information. <br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=User:Dstien&diff=838User:Dstien2008-06-22T15:04:21Z<p>Dstien: Wiping user page</p>
<hr />
<div><tt>Hello, world!</tt></div>Dstienhttps://wiki.stunts.hu/index.php?title=Replay_Handling&diff=837Replay Handling2008-06-22T15:00:59Z<p>Dstien: Pipsqueak wikilink</p>
<hr />
<div>A greatly helpful rule in online tournaments, which allows [[Pipsqueak|pipsqueaks]] to simply rewind the replay after a crash, or running off the road, and continue driving from some seconds earlier. This way you can not enter your name in Stunts' internal highscore table, but your final saved replay will be valid for online competitions. RH allows pipsqueaks to save a lot of time, achieve better results, and do insane stunts. <br />
There is an endless debate on RH in the community, whether it's a good thing, or not, but as there is no way to proof (without the usage of extrenal tools) whether a pipsqueak used RH or not, it's allowed by default.<br />
<br />
== See Also ==<br />
<br />
[[NoRH]]<br />
<br />
[[Category:Driving]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Time_hiding&diff=836Time hiding2008-06-22T15:00:02Z<p>Dstien: Pipsqueak wikilink</p>
<hr />
<div>A [[Pipsqueak|pipsqueak]] having a really fast, winning replay, but not sending it, only replays where he slows down at the end, reaching the pole position only with some milliseconds is called a time hider. Altough time hiding is slightly unethical, it's a key method for winning a track of hard battles.<br />
<br />
<br />
[[Category:Competition]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Talk:Game_versions&diff=832Talk:Game versions2008-06-19T19:24:39Z<p>Dstien: Reply</p>
<hr />
<div>If somebody knows how to avoid the PC9801 box pictures to be next to FM Towns box pictures, please correct it. ;-)<br />
I tried to put images in the middle of the text, but it's not enough. I also couldn't put the 3 images in one line. {{unsigned|Krys Toff|16:59, 19 June 2008 (CEST)}}<br />
:Added an example of the <tt><nowiki><gallery></nowiki></tt> tag. Forgot to log in. —[[User:Dstien|dstien]] 21:24, 19 June 2008 (CEST)</div>Dstienhttps://wiki.stunts.hu/index.php?title=Stunts_Wiki_talk:Cascading_protected_pages&diff=750Stunts Wiki talk:Cascading protected pages2008-05-13T23:50:00Z<p>Dstien: Reply</p>
<hr />
<div>How do you protect pages to be used by spam bots ? And how do you delete spam posts ? I saw these spam posts but didn't know how to delete them... <small>—Preceding [[Wikipedia:Wikipedia:Signatures|unsigned]] comment added by [[User:Krys Toff|Krys Toff]] ([[User talk:Krys Toff|talk]] • [[Special:Contributions/Krys Toff|contribs]]) 23:57, 13 May 2008 (CEST)</small><br />
:Users with sysop privileges[http://wiki.stunts.hu/index.php/Special:Listusers?group=sysop] get extra options in the wiki interface to delete and protect pages, and block users. The bots weren't able to defeat the CAPTCHA, but kept creating [[Index.php]] anyway without including external links, so I protected it. Let's see if it ends here... —[[User:Dstien|dstien]] 01:50, 14 May 2008 (CEST)</div>Dstienhttps://wiki.stunts.hu/index.php?title=Stunts_Wiki:Cascading_protected_pages&diff=748Stunts Wiki:Cascading protected pages2008-05-13T19:26:52Z<p>Dstien: Protected "Stunts Wiki:Cascading protected pages": Protect all included pages. [edit=sysop:move=sysop] [cascading]</p>
<hr />
<div>* {{:Index.php}}</div>Dstienhttps://wiki.stunts.hu/index.php?title=Stunts_Wiki:Cascading_protected_pages&diff=747Stunts Wiki:Cascading protected pages2008-05-13T19:25:01Z<p>Dstien: Protect non-existing pages.</p>
<hr />
<div>* {{:Index.php}}</div>Dstienhttps://wiki.stunts.hu/index.php?title=Shape_materials&diff=743Shape materials2008-05-05T23:17:13Z<p>Dstien: Added VGA palette indices for nifty sorting.</p>
<hr />
<div>3d shapes refers to a predefined set of materials. A material defines the appearance of a polygon with a color and a pattern. Most materials are opaque colors, while some have see-through patterns. Multiple polygons with different material patterns can be layered to achieve certain effects, such as multi-colored grilles and lights.<br />
<br />
==Materials==<br />
{| class="wikitable sortable"<br />
! # !! Hex # !! Pattern !! Color !! Pal # !! Name !! Comment<br />
|-<br />
| 0 || 0 || Opaque || <span style="color:#000000">████</span> <tt>000000</tt> || 0 || Black<br />
|-<br />
| 1 || 1 || Opaque || <span style="color:#0000A8">████</span> <tt>0000A8</tt> || 1 || Blue<br />
|-<br />
| 2 || 2 || Opaque || <span style="color:#00A800">████</span> <tt>00A800</tt> || 2 || Green<br />
|-<br />
| 3 || 3 || Opaque || <span style="color:#00A8A8">████</span> <tt>00A8A8</tt> || 3<br />
|-<br />
| 4 || 4 || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt> || 4 || || Highway light / cork l/r wall<br />
|-<br />
| 5 || 5 || Opaque || <span style="color:#A800A8">████</span> <tt>A800A8</tt> || 5<br />
|-<br />
| 6 || 6 || Opaque || <span style="color:#A85400">████</span> <tt>A85400</tt> || 6 || || Barn roof<br />
|-<br />
| 7 || 7 || Opaque || <span style="color:#A8A8A8">████</span> <tt>A8A8A8</tt> || 7 || || Gas station doors<br />
|-<br />
| 8 || 8 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt> || 8<br />
|-<br />
| 9 || 9 || Opaque || <span style="color:#5454FC">████</span> <tt>5454FC</tt> || 9<br />
|-<br />
| 10 || A || Opaque || <span style="color:#54FC54">████</span> <tt>54FC54</tt> || 10 || || Tree (pine)<br />
|-<br />
| 11 || B || Opaque || <span style="color:#54FCFC">████</span> <tt>54FCFC</tt> || 11<br />
|-<br />
| 12 || C || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt> || 12 || || Highway split light<br />
|-<br />
| 13 || D || Opaque || <span style="color:#FC54FC">████</span> <tt>FC54FC</tt> || 13<br />
|-<br />
| 14 || E || Opaque || <span style="color:#FCFC54">████</span> <tt>FCFC54</tt> || 14 || || Sharp turn sign<br />
|-<br />
| 15 || F || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt> || 15 || || Tennis court lines<br />
|-<br />
| 16 || 10 || Opaque || <span style="color:#246820">████</span> <tt>246820</tt> || 108 || || Grass<br />
|-<br />
| 17 || 11 || Opaque || <span style="color:#5CFCFC">████</span> <tt>5CFCFC</tt> || 116 || || Sky<br />
|-<br />
| 18 || 12 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt> || 15 || || Highway centerline<br />
|-<br />
| 19 || 13 || Opaque || <span style="color:#484848">████</span> <tt>484848</tt> || 28 || || Asphalt pavement<br />
|-<br />
| 20 || 14 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt> || 29 || || Tunnel centerline<br />
|-<br />
| 21 || 15 || Opaque || <span style="color:#FCFC54">████</span> <tt>FCFC54</tt> || 14 || || Asphalt centerline<br />
|-<br />
| 22 || 16 || Grate || <span style="color:#484848">▒▒▒▒</span> <tt>484848</tt> || 28 || || Loop / Elev. road surface <br />
|-<br />
| 23 || 17 || Grate || <span style="color:#202020">▒▒▒▒</span> <tt>202020</tt> || 31 || || Pipe surface<br />
|-<br />
| 24 || 18 || Grate || <span style="color:#FCFC54">▒▒▒▒</span> <tt>FCFC54</tt> || 14<br />
|-<br />
| 25 || 19 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt> || 200 || || Dirt pavement<br />
|-<br />
| 26 || 1A || Opaque || <span style="color:#B48054">████</span> <tt>B48054</tt> || 198<br />
|-<br />
| 27 || 1B || Opaque || <span style="color:#CCA080">████</span> <tt>CCA080</tt> || 196 || || Dirt centerline<br />
|-<br />
| 28 || 1C || Opaque || <span style="color:#D8FCFC">████</span> <tt>D8FCFC</tt> || 112 || || Ice pavement<br />
|-<br />
| 29 || 1D || Opaque || <span style="color:#9CFCFC">████</span> <tt>9CFCFC</tt> || 114<br />
|-<br />
| 30 || 1E || Opaque || <span style="color:#5CFCFC">████</span> <tt>5CFCFC</tt> || 116 || || Ice centerline<br />
|-<br />
| 31 || 1F || Opaque || <span style="color:#E4C4AC">████</span> <tt>E4C4AC</tt> || 194 || || Bridges, buildings, etc.<br />
|-<br />
| 32 || 20 || Opaque || <span style="color:#C0906C">████</span> <tt>C0906C</tt> || 197 || || Bridges, buildings, etc.<br />
|-<br />
| 33 || 21 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt> || 200 || || Bridges, buildings, etc.<br />
|-<br />
| 34 || 22 || Grate || <span style="color:#9C9CFC">▒▒▒▒</span> <tt>9C9CFC</tt> || 146<br />
|-<br />
| 35 || 23 || Opaque || <span style="color:#FC4040">████</span> <tt>FC4040</tt> || 37 || || Banked road outer side<br />
|-<br />
| 36 || 24 || Opaque || <span style="color:#FC7C7C">████</span> <tt>FC7C7C</tt> || 35 || || Tunnel walls / Bankings<br />
|-<br />
| 37 || 25 || Opaque || <span style="color:#FC40FC">████</span> <tt>FC40FC</tt> || 181 || || Bridge cables<br />
|-<br />
| 38 || 26 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt> || 29 || || Wheel (tyre tread)<br />
|-<br />
| 39 || 27 || Opaque || <span style="color:#202020">████</span> <tt>202020</tt> || 31 || || Wheel (tyre sidewall)<br />
|-<br />
| 40 || 28 || Opaque || <span style="color:#C0C0C0">████</span> <tt>C0C0C0</tt> || 19 || || Wheel ("rim")<br />
|-<br />
| 41 || 29 || Opaque || <span style="color:#00A8A8">████</span> <tt>00A8A8</tt> || 3 || || Windows (LM002 car1)<br />
|-<br />
| 42 || 2A || Opaque || <span style="color:#54FCFC">████</span> <tt>54FCFC</tt> || 11 || || Gas station windows<br />
|-<br />
| 43 || 2B || Opaque || <span style="color:#545454">████</span> <tt>545454</tt> || 8 || || Windows and windshields<br />
|-<br />
| 44 || 2C || Opaque || <span style="color:#000000">████</span> <tt>000000</tt> || 0 || || Windows and windshields<br />
|-<br />
| 45 || 2D || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt> || 4<br />
|-<br />
| 46 || 2E || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt> || 4<br />
|-<br />
| 47 || 2F || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt> || 12<br />
|-<br />
| 48 || 30 || Opaque || <span style="color:#00007C">████</span> <tt>00007C</tt> || 156 || Blue 1 || Car body<br />
|-<br />
| 49 || 31 || Opaque || <span style="color:#0000A8">████</span> <tt>0000A8</tt> || 1 || Blue 2 || Car body<br />
|-<br />
| 50 || 32 || Opaque || <span style="color:#0000D0">████</span> <tt>0000D0</tt> || 152 || Blue 3 || Car body<br />
|-<br />
| 51 || 33 || Opaque || <span style="color:#0004FC">████</span> <tt>0004FC</tt> || 150 || Blue 4 || Car body<br />
|-<br />
| 52 || 34 || Opaque || <span style="color:#B40000">████</span> <tt>B40000</tt> || 42 || Red 1 || Car body<br />
|-<br />
| 53 || 35 || Opaque || <span style="color:#E40000">████</span> <tt>E40000</tt> || 40 || Red 2 || Car body<br />
|-<br />
| 54 || 36 || Opaque || <span style="color:#FC2020">████</span> <tt>FC2020</tt> || 38 || Red 3 || Car body<br />
|-<br />
| 55 || 37 || Opaque || <span style="color:#FC4040">████</span> <tt>FC4040</tt> || 37 || Red 4 || Car body<br />
|-<br />
| 56 || 38 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt> || 8 || Graphite 1 || Car body<br />
|-<br />
| 57 || 39 || Opaque || <span style="color:#606060">████</span> <tt>606060</tt> || 26 || Graphite 2 || Car body<br />
|-<br />
| 58 || 3A || Opaque || <span style="color:#707070">████</span> <tt>707070</tt> || 25 || Graphite 3 || Car body<br />
|-<br />
| 59 || 3B || Opaque || <span style="color:#7C7C7C">████</span> <tt>7C7C7C</tt> || 24 || Graphite 4 || Car body<br />
|-<br />
| 60 || 3C || Opaque || <span style="color:#E4D800">████</span> <tt>E4D800</tt> || 72 || Yellow 1 || Car body<br />
|-<br />
| 61 || 3D || Opaque || <span style="color:#FCF420">████</span> <tt>FCF420</tt> || 70 || Yellow 2 || Car body<br />
|-<br />
| 62 || 3E || Opaque || <span style="color:#FCF85C">████</span> <tt>FCF85C</tt> || 68 || Yellow 3 || Car body<br />
|-<br />
| 63 || 3F || Opaque || <span style="color:#FCFC9C">████</span> <tt>FCFC9C</tt> || 66 || Yellow 4 || Car body<br />
|-<br />
| 64 || 40 || Opaque || <span style="color:#009C9C">████</span> <tt>009C9C</tt> || 123 || Cyan 1 || Car body<br />
|-<br />
| 65 || 41 || Opaque || <span style="color:#00CCCC">████</span> <tt>00CCCC</tt> || 121 || Cyan 2 || Car body<br />
|-<br />
| 66 || 42 || Opaque || <span style="color:#00E4E4">████</span> <tt>00E4E4</tt> || 120 || Cyan 3 || Car body<br />
|-<br />
| 67 || 43 || Opaque || <span style="color:#40FCFC">████</span> <tt>40FCFC</tt> || 117 || Cyan 4 || Car body<br />
|-<br />
| 68 || 44 || Opaque || <span style="color:#508400">████</span> <tt>508400</tt> || 92 || Green 1 || Car body / Tree (palm)<br />
|-<br />
| 69 || 45 || Opaque || <span style="color:#74B400">████</span> <tt>74B400</tt> || 90 || Green 2 || Car body / Tree (palm)<br />
|-<br />
| 70 || 46 || Opaque || <span style="color:#90E400">████</span> <tt>90E400</tt> || 88 || Green 3 || Car body / Tree (palm)<br />
|-<br />
| 71 || 47 || Opaque || <span style="color:#A0FC00">████</span> <tt>A0FC00</tt> || 87 || Green 4 || Car body<br />
|-<br />
| 72 || 48 || Opaque || <span style="color:#440070">████</span> <tt>440070</tt> || 173 || Purple 1 || Car body<br />
|-<br />
| 73 || 49 || Opaque || <span style="color:#60009C">████</span> <tt>60009C</tt> || 171 || Purple 2 || Car body<br />
|-<br />
| 74 || 4A || Opaque || <span style="color:#8000CC">████</span> <tt>8000CC</tt> || 169 || Purple 3 || Car body<br />
|-<br />
| 75 || 4B || Opaque || <span style="color:#A800FC">████</span> <tt>A800FC</tt> || 167 || Purple 4 || Car body<br />
|-<br />
| 76 || 4C || Opaque || <span style="color:#B0B0B0">████</span> <tt>B0B0B0</tt> || 20 || Silver 1 || Car body<br />
|-<br />
| 77 || 4D || Opaque || <span style="color:#C0C0C0">████</span> <tt>C0C0C0</tt> || 19 || Silver 2 || Car body<br />
|-<br />
| 78 || 4E || Opaque || <span style="color:#CCCCCC">████</span> <tt>CCCCCC</tt> || 18 || Silver 3 || Car body<br />
|-<br />
| 79 || 4F || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt> || 17 || Silver 4 || Car body<br />
|-<br />
| 80 || 50 || Opaque || <span style="color:#6C5800">████</span> <tt>6C5800</tt> || 77 || Golden 1 || Car body<br />
|-<br />
| 81 || 51 || Opaque || <span style="color:#847400">████</span> <tt>847400</tt> || 76 || Golden 2 || Car body<br />
|-<br />
| 82 || 52 || Opaque || <span style="color:#B4A400">████</span> <tt>B4A400</tt> || 74 || Golden 3 || Car body<br />
|-<br />
| 83 || 53 || Opaque || <span style="color:#CCC000">████</span> <tt>CCC000</tt> || 73 || Golden 4 || Car body<br />
|-<br />
| 84 || 54 || Opaque || <span style="color:#700000">████</span> <tt>700000</tt> || 45 || Burgundy 1 || Car body<br />
|-<br />
| 85 || 55 || Opaque || <span style="color:#840000">████</span> <tt>840000</tt> || 44 || Burgundy 2 || Car body<br />
|-<br />
| 86 || 56 || Opaque || <span style="color:#B40000">████</span> <tt>B40000</tt> || 42 || Burgundy 3 || Car body<br />
|-<br />
| 87 || 57 || Opaque || <span style="color:#CC0000">████</span> <tt>CC0000</tt> || 41 || Burgundy 4 || Car body<br />
|-<br />
| 88 || 58 || Opaque || <span style="color:#000040">████</span> <tt>000040</tt> || 159 || Violet 1 || Car body<br />
|-<br />
| 89 || 59 || Opaque || <span style="color:#280040">████</span> <tt>280040</tt> || 175 || Violet 2 || Car body<br />
|-<br />
| 90 || 5A || Opaque || <span style="color:#340058">████</span> <tt>340058</tt> || 174 || Violet 3 || Car body<br />
|-<br />
| 91 || 5B || Opaque || <span style="color:#500084">████</span> <tt>500084</tt> || 172 || Violet 4 || Car body<br />
|-<br />
| 92 || 5C || Opaque || <span style="color:#383838">████</span> <tt>383838</tt> || 29<br />
|-<br />
| 93 || 5D || Opaque || <span style="color:#484848">████</span> <tt>484848</tt> || 28<br />
|-<br />
| 94 || 5E || Grate || <span style="color:#CCCCCC">▒▒▒▒</span> <tt>CCCCCC</tt> || 18 || || Tennis net<br />
|-<br />
| 95 || 5F || Opaque || <span style="color:#74B400">████</span> <tt>74B400</tt> || 90 || || Tennis grass<br />
|-<br />
| 96 || 60 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt> || 15 || || Clouds<br />
|-<br />
| 97 || 61 || Opaque || <span style="color:#A8A8A8">████</span> <tt>A8A8A8</tt> || 7 || || Clouds<br />
|-<br />
| 98 || 62 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt> || 200 || || Pinetree trunk<br />
|-<br />
| 99 || 63 || Opaque || <span style="color:#C0602C">████</span> <tt>C0602C</tt> || 219 || || Pinetree trunk<br />
|-<br />
| 100 || 64 || Opaque || <span style="color:#0080D0">████</span> <tt>0080D0</tt> || 136 || || Water<br />
|-<br />
| 101 || 65 || Opaque || <span style="color:#84E084">████</span> <tt>84E084</tt> || 99 || || Grass (hilltop)<br />
|-<br />
| 102 || 66 || Opaque || <span style="color:#70C46C">████</span> <tt>70C46C</tt> || 101 || || Grass (hill slope)<br />
|-<br />
| 103 || 67 || Opaque || <span style="color:#58A858">████</span> <tt>58A858</tt> || 103 || || Grass (angled slope)<br />
|-<br />
| 104 || 68 || Opaque || <span style="color:#509C4C">████</span> <tt>509C4C</tt> || 104 || || Grass (angled slope)<br />
|-<br />
| 105 || 69 || Opaque || <span style="color:#388034">████</span> <tt>388034</tt> || 106 || || Grass (angled slope)<br />
|-<br />
| 106 || 6A || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt> || 17 || || Gas station / Joe's<br />
|-<br />
| 107 || 6B || Opaque || <span style="color:#B0B0B0">████</span> <tt>B0B0B0</tt> || 20 || || Gas station / Joe's<br />
|-<br />
| 108 || 6C || Opaque || <span style="color:#905410">████</span> <tt>905410</tt> || 60 || || Trunk (palmtree)<br />
|-<br />
| 109 || 6D || Opaque || <span style="color:#6C5800">████</span> <tt>6C5800</tt> || 77 || || Trunk (palmtree)<br />
|-<br />
| 110 || 6E || Opaque || <span style="color:#580000">████</span> <tt>580000</tt> || 46 || || Joe's roof<br />
|-<br />
| 111 || 6F || Opaque || <span style="color:#744008">████</span> <tt>744008</tt> || 61 || || Windmill (base)<br />
|-<br />
| 112 || 70 || Opaque || <span style="color:#700000">████</span> <tt>700000</tt> || 45 || || Windmill (base)<br />
|-<br />
| 113 || 71 || Opaque || <span style="color:#80542C">████</span> <tt>80542C</tt> || 202 || || Windmill (blades)<br />
|-<br />
| 114 || 72 || Opaque || <span style="color:#540054">████</span> <tt>540054</tt> || 190 || || Joe's flashing sign<br />
|-<br />
| 115 || 73 || Opaque || <span style="color:#A400A4">████</span> <tt>A400A4</tt> || 186 || || Joe's flashing sign<br />
|-<br />
| 116 || 74 || Opaque || <span style="color:#E000E4">████</span> <tt>E000E4</tt> || 183 || || Joe's flashing sign<br />
|-<br />
| 117 || 75 || Opaque || <span style="color:#FC5CFC">████</span> <tt>FC5CFC</tt> || 180 || || Joe's flashing sign<br />
|-<br />
| 118 || 76 || Transparent || <span style="color:#FFFFFF"></span> <tt>N/A</tt> || 255 || || Windmill animation mask<br />
|-<br />
| 119 || 77 || Grille || <span style="color:#484848">▒▒▒▒</span> <tt>484848</tt> || 28<br />
|-<br />
| 120 || 78 || Inverse grille || <span style="color:#2C2C2C">▒▒▒▒</span> <tt>2C2C2C</tt> || 30<br />
|-<br />
| 121 || 79 || Glass || <span style="color:#FCFCFC">▓▓▓▓</span> <tt>FCFCFC</tt> || 15<br />
|-<br />
| 122 || 7A || Inverse glass || <span style="color:#B0B0B0">░░░░</span> <tt>B0B0B0</tt> || 20<br />
|-<br />
| 123 || 7B || Glass || <span style="color:#FCF85C">▓▓▓▓</span> <tt>FCF85C</tt> || 68<br />
|-<br />
| 124 || 7C || Inverse glass || <span style="color:#FCAC54">░░░░</span> <tt>FCAC54</tt> || 54<br />
|-<br />
| 125 || 7D || Glass || <span style="color:#FC0000">▓▓▓▓</span> <tt>FC0000</tt> || 39<br />
|-<br />
| 126 || 7E || Inverse glass || <span style="color:#9C0000">░░░░</span> <tt>9C0000</tt> || 43<br />
|-<br />
| 127 || 7F || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt> || 12 || || Corner kerbs<br />
|-<br />
| 128 || 80 || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt> || 17 || || Corner kerbs<br />
|}<br />
<br />
==Patterns==<br />
Patterns are used as a mask when drawing the polygon akin to polygon stippling in OpenGL.<br />
<br />
<gallery widths="128px" heights="128px" perrow="3"><br />
Image:Pattern_Grille.png|Grille<br />
Image:Pattern_Glass.png|Glass (lights)<br />
Image:Pattern_Grate.png|Grate (ramps, bridges)<br />
Image:Pattern_Grille_Inverse.png|Inverse grille<br />
Image:Pattern_Glass_Inverse.png|Inverse glass<br />
</gallery><br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=708Resource file format2008-04-28T18:36:07Z<p>Dstien: /* 3d shapes */ Added some details I encountered while implementing a shape file writer.</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple ''resources'', blocks of data that may be of various types - text, bitmaps, sounds, etc. Resources are uniquely identified within each file solely by a 4-byte name. A resource container file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span class="hlC">// Header</span><br />
<span class="hlP">uint32</span> fileLength<br />
<span class="hlP">uint16</span> numResources<br />
<br />
<span class="hlC">// Table of contents</span><br />
<span class="hlP">char</span> ids<span class="hlB">[</span>numResources<span class="hlB">][</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint32</span> offsets<span class="hlB">[</span>numResources<span class="hlB">]</span><br />
<br />
<span class="hlC">// Resource data</span><br />
<span class="hlP">char</span> data<span class="hlB">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span class="hlP">uint16</span> width<br />
<span class="hlP">uint16</span> height<br />
<span class="hlP">uint16</span> unknown1<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint8</span> unknown2<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> image<span class="hlB">[</span>width <span class="hlB">*</span> height<span class="hlB">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' internal memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression]. Images with pixel data stored as continuos horizontal lines has <tt>unknown2</tt> set to <code>{ 0x1, 0x2, 0x4, 0x8 }</code>.<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
Shapes are composed of a vertex list and a list of primitives. Primitives are basic shapes that can have different types, such as polygons or wheels. Depending on the type it contains a number of indices into the vertex list needed to draw the shape, color variations and some rendering hints. Stunts' coordinate system use 16-bit signed integers, making the resolution relative to the scale of the model. Shapes presented in the car selection screen are more detailed than in-game shapes, thus requiring larger scaling.<br />
<br />
Due to the counter header fields being stored in single bytes, the total amount of vertices and primitives are limited to 255 per shape.<br />
<br />
'''Main strcture'''<br />
<span class="hlP">uint8</span> numVertices<br />
<span class="hlP">uint8</span> numPrimitives<br />
<span class="hlP">uint8</span> numPaintJobs<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always == 0</span><br />
<br />
VERTEX vertices<span class="hlB">[</span>numVertices<span class="hlB">]</span><br />
UNKNOWN unknowns<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
PRIMITIVE primitives<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> terminate<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// One or two NULL-bytes to make resource size divisible by 2.</span><br />
<br />
'''Additional structures'''<br />
<span class="hlP">struct</span> VERTEX <span class="hlB">{</span><br />
<span class="hlP">int16</span> x<br />
<span class="hlP">int16</span> y<br />
<span class="hlP">int16</span> z<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> UNKNOWN <span class="hlB">{</span><br />
<span class="hlP">int8</span> data<span class="hlB">[</span><span class="hlN">8</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> PRIMITIVE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> type<br />
<span class="hlP">uint8</span> depthIndex<br />
<span class="hlP">uint8</span> materials<span class="hlB">[</span>numPaintJobs<span class="hlB">]</span><br />
<span class="hlP">uint8</span> indices<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// Size depends on type.</span><br />
<span class="hlB">}</span><br />
<br />
'''Primitive types'''<br />
{| class="wikitable"<br />
! Primitive type !! Vertex indices needed !! Description<br />
|-<br />
| 1 || 1 || Particle, 1 pixel<br />
|-<br />
| 2 || 2 || Line segment, 1 pixel width<br />
|-<br />
| 3–10 || 3–10 || Polygon, ''n'' sides<br />
|-<br />
| 11 || 2 || Sphere (center + ~(radius / 2)<br />
|-<br />
| 12 || 6 || Wheel<br />
|-<br />
| * || 0 || Ignored<br />
|}<br />
<br />
For car body and track element shapes the first eight vertices are reserved for the corner vertices of the shape's bound box, used to cull entire shapes located outside the view frustum.<br />
<br />
[[Image:Wheel_Primitive_Anatomy.png|200px|right|thumb|Anatomy of a wheel shape primitive.]]<br />
The first three vertices in a wheel primitive marks the center, tire radius and rim radius for the inner wheel-half facing the vehicle. The last three vertices does the same, in the same order, for the outer half of the wheel. Directions does not matter, the vertex locations are only used to measure distances. This rule applies to the sphere primitive as well.<br />
<br />
Wheel transformations are performed on fixed vertex positions. Since the first eight vertices of <tt>car[0-2]</tt> shapes are occupied by the bound box, vertices 9-14 and 15-20 are front wheels. Misplaced wheel vertices will lead to corrupted shape rendering.<br />
<br />
The value <tt>depthIndex</tt> in the <tt>PRIMITIVE</tt> structure is used to override the game's depth clipping in order to avoid flickering when several primitives are being drawn at the exact same depth. Higher value gives the primitive higher precedence.<br />
<br />
[[Shape materials|Materials]] are indices into a permanent, internal game structure and are assigned per-primitive. Cars can have multiple paint jobs, every primitive in the shape must set a material for each color scheme.<br />
<br />
Experimentation has revealed that <tt>UNKNOWN</tt> data at least partially controls occlusion culling on primitive level. How, and exactly which parts of this structure does what has yet to be understood.<br />
<br />
A shape resource must be terminated with a NULL-byte and the size must be divisible by two, hence two NULL-bytes are needed to terminate and pad resources with an even number of bytes. Failing to meet this requirement will lead to obscure rendering artifacts.<br />
<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Shape_materials&diff=701Shape materials2008-04-28T00:32:28Z<p>Dstien: Category.</p>
<hr />
<div>3d shapes refers to a predefined set of materials. A material defines the appearance of a polygon with a color and a pattern. Most materials are opaque colors, while some have see-through patterns. Multiple polygons with different material patterns can be layered to achieve certain effects, such as multi-colored grilles and lights.<br />
<br />
==Materials==<br />
{| class="wikitable sortable"<br />
! # !! Pattern !! Color !! Name !! Comment<br />
|-<br />
| 0 || Opaque || <span style="color:#000000">████</span> <tt>000000</tt> || Black<br />
|-<br />
| 1 || Opaque || <span style="color:#0000A8">████</span> <tt>0000A8</tt> || Blue<br />
|-<br />
| 2 || Opaque || <span style="color:#00A800">████</span> <tt>00A800</tt> || Green<br />
|-<br />
| 3 || Opaque || <span style="color:#00A8A8">████</span> <tt>00A8A8</tt><br />
|-<br />
| 4 || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt><br />
|-<br />
| 5 || Opaque || <span style="color:#A800A8">████</span> <tt>A800A8</tt><br />
|-<br />
| 6 || Opaque || <span style="color:#A85400">████</span> <tt>A85400</tt><br />
|-<br />
| 7 || Opaque || <span style="color:#A8A8A8">████</span> <tt>A8A8A8</tt><br />
|-<br />
| 8 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt><br />
|-<br />
| 9 || Opaque || <span style="color:#5454FC">████</span> <tt>5454FC</tt><br />
|-<br />
| 10 || Opaque || <span style="color:#54FC54">████</span> <tt>54FC54</tt><br />
|-<br />
| 11 || Opaque || <span style="color:#54FCFC">████</span> <tt>54FCFC</tt><br />
|-<br />
| 12 || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt><br />
|-<br />
| 13 || Opaque || <span style="color:#FC54FC">████</span> <tt>FC54FC</tt><br />
|-<br />
| 14 || Opaque || <span style="color:#FCFC54">████</span> <tt>FCFC54</tt><br />
|-<br />
| 15 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt><br />
|-<br />
| 16 || Opaque || <span style="color:#246820">████</span> <tt>246820</tt> || Green || Grass<br />
|-<br />
| 17 || Opaque || <span style="color:#5CFCFC">████</span> <tt>5CFCFC</tt> || Cyan || Sky<br />
|-<br />
| 18 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt><br />
|-<br />
| 19 || Opaque || <span style="color:#484848">████</span> <tt>484848</tt><br />
|-<br />
| 20 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt><br />
|-<br />
| 21 || Opaque || <span style="color:#FCFC54">████</span> <tt>FCFC54</tt><br />
|-<br />
| 22 || Grate || <span style="color:#484848">▒▒▒▒</span> <tt>484848</tt><br />
|-<br />
| 23 || Grate || <span style="color:#202020">▒▒▒▒</span> <tt>202020</tt><br />
|-<br />
| 24 || Grate || <span style="color:#FCFC54">▒▒▒▒</span> <tt>FCFC54</tt><br />
|-<br />
| 25 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt><br />
|-<br />
| 26 || Opaque || <span style="color:#B48054">████</span> <tt>B48054</tt><br />
|-<br />
| 27 || Opaque || <span style="color:#CCA080">████</span> <tt>CCA080</tt><br />
|-<br />
| 28 || Opaque || <span style="color:#D8FCFC">████</span> <tt>D8FCFC</tt><br />
|-<br />
| 29 || Opaque || <span style="color:#9CFCFC">████</span> <tt>9CFCFC</tt><br />
|-<br />
| 30 || Opaque || <span style="color:#5CFCFC">████</span> <tt>5CFCFC</tt><br />
|-<br />
| 31 || Opaque || <span style="color:#E4C4AC">████</span> <tt>E4C4AC</tt><br />
|-<br />
| 32 || Opaque || <span style="color:#C0906C">████</span> <tt>C0906C</tt><br />
|-<br />
| 33 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt><br />
|-<br />
| 34 || Grate || <span style="color:#9C9CFC">▒▒▒▒</span> <tt>9C9CFC</tt><br />
|-<br />
| 35 || Opaque || <span style="color:#FC4040">████</span> <tt>FC4040</tt><br />
|-<br />
| 36 || Opaque || <span style="color:#FC7C7C">████</span> <tt>FC7C7C</tt><br />
|-<br />
| 37 || Opaque || <span style="color:#FC40FC">████</span> <tt>FC40FC</tt><br />
|-<br />
| 38 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt><br />
|-<br />
| 39 || Opaque || <span style="color:#202020">████</span> <tt>202020</tt><br />
|-<br />
| 40 || Opaque || <span style="color:#C0C0C0">████</span> <tt>C0C0C0</tt><br />
|-<br />
| 41 || Opaque || <span style="color:#00A8A8">████</span> <tt>00A8A8</tt><br />
|-<br />
| 42 || Opaque || <span style="color:#54FCFC">████</span> <tt>54FCFC</tt><br />
|-<br />
| 43 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt><br />
|-<br />
| 44 || Opaque || <span style="color:#000000">████</span> <tt>000000</tt><br />
|-<br />
| 45 || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt><br />
|-<br />
| 46 || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt><br />
|-<br />
| 47 || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt><br />
|-<br />
| 48 || Opaque || <span style="color:#00007C">████</span> <tt>00007C</tt> || Blue 1 || Car body<br />
|-<br />
| 49 || Opaque || <span style="color:#0000A8">████</span> <tt>0000A8</tt> || Blue 2 || Car body<br />
|-<br />
| 50 || Opaque || <span style="color:#0000D0">████</span> <tt>0000D0</tt> || Blue 3 || Car body<br />
|-<br />
| 51 || Opaque || <span style="color:#0004FC">████</span> <tt>0004FC</tt> || Blue 4 || Car body<br />
|-<br />
| 52 || Opaque || <span style="color:#B40000">████</span> <tt>B40000</tt> || Red 1 || Car body<br />
|-<br />
| 53 || Opaque || <span style="color:#E40000">████</span> <tt>E40000</tt> || Red 2 || Car body<br />
|-<br />
| 54 || Opaque || <span style="color:#FC2020">████</span> <tt>FC2020</tt> || Red 3 || Car body<br />
|-<br />
| 55 || Opaque || <span style="color:#FC4040">████</span> <tt>FC4040</tt> || Red 4 || Car body<br />
|-<br />
| 56 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt> || Graphite 1 || Car body<br />
|-<br />
| 57 || Opaque || <span style="color:#606060">████</span> <tt>606060</tt> || Graphite 2 || Car body<br />
|-<br />
| 58 || Opaque || <span style="color:#707070">████</span> <tt>707070</tt> || Graphite 3 || Car body<br />
|-<br />
| 59 || Opaque || <span style="color:#7C7C7C">████</span> <tt>7C7C7C</tt> || Graphite 4 || Car body<br />
|-<br />
| 60 || Opaque || <span style="color:#E4D800">████</span> <tt>E4D800</tt> || Yellow 1 || Car body<br />
|-<br />
| 61 || Opaque || <span style="color:#FCF420">████</span> <tt>FCF420</tt> || Yellow 2 || Car body<br />
|-<br />
| 62 || Opaque || <span style="color:#FCF85C">████</span> <tt>FCF85C</tt> || Yellow 3 || Car body<br />
|-<br />
| 63 || Opaque || <span style="color:#FCFC9C">████</span> <tt>FCFC9C</tt> || Yellow 4 || Car body<br />
|-<br />
| 64 || Opaque || <span style="color:#009C9C">████</span> <tt>009C9C</tt> || Cyan 1 || Car body<br />
|-<br />
| 65 || Opaque || <span style="color:#00CCCC">████</span> <tt>00CCCC</tt> || Cyan 2 || Car body<br />
|-<br />
| 66 || Opaque || <span style="color:#00E4E4">████</span> <tt>00E4E4</tt> || Cyan 3 || Car body<br />
|-<br />
| 67 || Opaque || <span style="color:#40FCFC">████</span> <tt>40FCFC</tt> || Cyan 4 || Car body<br />
|-<br />
| 68 || Opaque || <span style="color:#508400">████</span> <tt>508400</tt> || Green 1 || Car body<br />
|-<br />
| 69 || Opaque || <span style="color:#74B400">████</span> <tt>74B400</tt> || Green 2 || Car body<br />
|-<br />
| 70 || Opaque || <span style="color:#90E400">████</span> <tt>90E400</tt> || Green 3 || Car body<br />
|-<br />
| 71 || Opaque || <span style="color:#A0FC00">████</span> <tt>A0FC00</tt> || Green 4 || Car body<br />
|-<br />
| 72 || Opaque || <span style="color:#440070">████</span> <tt>440070</tt> || Purple 1 || Car body<br />
|-<br />
| 73 || Opaque || <span style="color:#60009C">████</span> <tt>60009C</tt> || Purple 2 || Car body<br />
|-<br />
| 74 || Opaque || <span style="color:#8000CC">████</span> <tt>8000CC</tt> || Purple 3 || Car body<br />
|-<br />
| 75 || Opaque || <span style="color:#A800FC">████</span> <tt>A800FC</tt> || Purple 4 || Car body<br />
|-<br />
| 76 || Opaque || <span style="color:#B0B0B0">████</span> <tt>B0B0B0</tt> || Silver 1 || Car body<br />
|-<br />
| 77 || Opaque || <span style="color:#C0C0C0">████</span> <tt>C0C0C0</tt> || Silver 2 || Car body<br />
|-<br />
| 78 || Opaque || <span style="color:#CCCCCC">████</span> <tt>CCCCCC</tt> || Silver 3 || Car body<br />
|-<br />
| 79 || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt> || Silver 4 || Car body<br />
|-<br />
| 80 || Opaque || <span style="color:#6C5800">████</span> <tt>6C5800</tt> || Golden 1 || Car body<br />
|-<br />
| 81 || Opaque || <span style="color:#847400">████</span> <tt>847400</tt> || Golden 2 || Car body<br />
|-<br />
| 82 || Opaque || <span style="color:#B4A400">████</span> <tt>B4A400</tt> || Golden 3 || Car body<br />
|-<br />
| 83 || Opaque || <span style="color:#CCC000">████</span> <tt>CCC000</tt> || Golden 4 || Car body<br />
|-<br />
| 84 || Opaque || <span style="color:#700000">████</span> <tt>700000</tt> || Burgundy 1 || Car body<br />
|-<br />
| 85 || Opaque || <span style="color:#840000">████</span> <tt>840000</tt> || Burgundy 2 || Car body<br />
|-<br />
| 86 || Opaque || <span style="color:#B40000">████</span> <tt>B40000</tt> || Burgundy 3 || Car body<br />
|-<br />
| 87 || Opaque || <span style="color:#CC0000">████</span> <tt>CC0000</tt> || Burgundy 4 || Car body<br />
|-<br />
| 88 || Opaque || <span style="color:#000040">████</span> <tt>000040</tt> || Violet 1 || Car body<br />
|-<br />
| 89 || Opaque || <span style="color:#280040">████</span> <tt>280040</tt> || Violet 2 || Car body<br />
|-<br />
| 90 || Opaque || <span style="color:#340058">████</span> <tt>340058</tt> || Violet 3 || Car body<br />
|-<br />
| 91 || Opaque || <span style="color:#500084">████</span> <tt>500084</tt> || Violet 4 || Car body<br />
|-<br />
| 92 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt><br />
|-<br />
| 93 || Opaque || <span style="color:#484848">████</span> <tt>484848</tt><br />
|-<br />
| 94 || Grate || <span style="color:#CCCCCC">▒▒▒▒</span> <tt>CCCCCC</tt> || || Tennis net<br />
|-<br />
| 95 || Opaque || <span style="color:#74B400">████</span> <tt>74B400</tt> || || Tennis grass<br />
|-<br />
| 96 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt><br />
|-<br />
| 97 || Opaque || <span style="color:#A8A8A8">████</span> <tt>A8A8A8</tt><br />
|-<br />
| 98 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt><br />
|-<br />
| 99 || Opaque || <span style="color:#C0602C">████</span> <tt>C0602C</tt><br />
|-<br />
| 100 || Opaque || <span style="color:#0080D0">████</span> <tt>0080D0</tt><br />
|-<br />
| 101 || Opaque || <span style="color:#84E084">████</span> <tt>84E084</tt> || || Grass<br />
|-<br />
| 102 || Opaque || <span style="color:#70C46C">████</span> <tt>70C46C</tt> || || Grass<br />
|-<br />
| 103 || Opaque || <span style="color:#58A858">████</span> <tt>58A858</tt> || || Grass<br />
|-<br />
| 104 || Opaque || <span style="color:#509C4C">████</span> <tt>509C4C</tt> || || Grass<br />
|-<br />
| 105 || Opaque || <span style="color:#388034">████</span> <tt>388034</tt> || || Grass<br />
|-<br />
| 106 || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt><br />
|-<br />
| 107 || Opaque || <span style="color:#B0B0B0">████</span> <tt>B0B0B0</tt><br />
|-<br />
| 108 || Opaque || <span style="color:#905410">████</span> <tt>905410</tt><br />
|-<br />
| 109 || Opaque || <span style="color:#6C5800">████</span> <tt>6C5800</tt><br />
|-<br />
| 110 || Opaque || <span style="color:#580000">████</span> <tt>580000</tt><br />
|-<br />
| 111 || Opaque || <span style="color:#744008">████</span> <tt>744008</tt><br />
|-<br />
| 112 || Opaque || <span style="color:#700000">████</span> <tt>700000</tt><br />
|-<br />
| 113 || Opaque || <span style="color:#80542C">████</span> <tt>80542C</tt><br />
|-<br />
| 114 || Opaque || <span style="color:#540054">████</span> <tt>540054</tt><br />
|-<br />
| 115 || Opaque || <span style="color:#A400A4">████</span> <tt>A400A4</tt><br />
|-<br />
| 116 || Opaque || <span style="color:#E000E4">████</span> <tt>E000E4</tt><br />
|-<br />
| 117 || Opaque || <span style="color:#FC5CFC">████</span> <tt>FC5CFC</tt><br />
|-<br />
| 118 || Transparent || <span style="color:#FFFFFF"></span> <tt>N/A</tt> || || Windmill animation mask<br />
|-<br />
| 119 || Grille || <span style="color:#484848">▒▒▒▒</span> <tt>484848</tt><br />
|-<br />
| 120 || Inverse grille || <span style="color:#2C2C2C">▒▒▒▒</span> <tt>2C2C2C</tt><br />
|-<br />
| 121 || Glass || <span style="color:#FCFCFC">▓▓▓▓</span> <tt>FCFCFC</tt><br />
|-<br />
| 122 || Inverse glass || <span style="color:#B0B0B0">░░░░</span> <tt>B0B0B0</tt><br />
|-<br />
| 123 || Glass || <span style="color:#FCF85C">▓▓▓▓</span> <tt>FCF85C</tt><br />
|-<br />
| 124 || Inverse glass || <span style="color:#FCAC54">░░░░</span> <tt>FCAC54</tt><br />
|-<br />
| 125 || Glass || <span style="color:#FC0000">▓▓▓▓</span> <tt>FC0000</tt><br />
|-<br />
| 126 || Inverse glass || <span style="color:#9C0000">░░░░</span> <tt>9C0000</tt><br />
|-<br />
| 127 || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt><br />
|-<br />
| 128 || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt><br />
|}<br />
<br />
==Patterns==<br />
Patterns are used as a mask when drawing the polygon akin to polygon stippling in OpenGL.<br />
<br />
<gallery widths="128px" heights="128px" perrow="3"><br />
Image:Pattern_Grille.png|Grille<br />
Image:Pattern_Glass.png|Glass (lights)<br />
Image:Pattern_Grate.png|Grate (ramps, bridges)<br />
Image:Pattern_Grille_Inverse.png|Inverse grille<br />
Image:Pattern_Glass_Inverse.png|Inverse glass<br />
</gallery><br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Car_files&diff=700Car files2008-04-28T00:04:13Z<p>Dstien: /* Editing and combining car graphics */ dstein → dstien</p>
<hr />
<div>Stunts cars are made of four different [[Resource file format|resource files]]: st*.p3s, stda*.pvs, stdb*.pvs and car*.res ; where the * stands for an arbitrary 4-letter abbreviation shared by files of the same car. All of the car graphics are stored in the [[Compression|compressed]] .p3s and .pvs files. The car*.res contains numerical and text parameters, including data about car performance essential to the creation of [[Cheated Cars|tuned cars]]. <br />
<br />
==Graphics files (.p3s/.pvs)==<br />
<br />
Different aspects of a car's appearance are stored in each of the graphic files:<br />
<br />
*'''st*.p3s''' - [[Resource file format#3d shapes|3d shape resource]] file that stores the graphical 3D models of the car, including their colour data.<br />
*'''stda*.pvs''' - [[Resource file format#Bitmap images|Bitmap resource]] file that contains the dashboard image, including the shifting stick's base. <br />
*'''stdb*.pvs''' - [[Resource file format#Bitmap images|Bitmap resource]] file that contains the shifting knob. For the [[Corvette ZR1|Corvette]], it also stores the digital speedometer graphics.<br />
<br />
Each of the files contain a number of independent resources, used on different places or in-game situations. Here a rundown of those resources contained within each file will be presented. For an explanation of internal structure of the resources, applicable to all files here discussed, check the [[Resource file format]] article. It is important to emphasize all graphics files are [[Compression|compressed]], and thus any visualization or edition of structure calls for prior decompression. <br />
<br />
===3D shapes (st*.p3s)===<br />
[[image:Resdifcar0car1.png|240px|right|thumb|An illustration of the resolution differences between car0 and car1 shapes. On this image, car0 was used instead of the usual car1 to render the Indycar on-track. The screenshot was taken with the car on the ground, and under F3 camera fully zoomed out.]]<br />
Standard st*.p3s files contain seven 3D shape resources, each being used in different circumstances: <br />
<br />
*'''car0''' shape is the one used in the car selection screen. It is richly detailed for Stunts usual standards, and has pretty high internal resolution. <br />
*'''car1''' shape corresponds to the car actually rendered on-track. Its resolution is much smaller than the car0 shape, the scaling down factor being in the order of 1:20, thus explaining why many fine details seen on the "showroom" car are not seen on-track. <br />
*'''car2''' shape is the very long distance model, used only for the initial zoom-in animation that precedes the "Fasten your seatbelt!" message at the start of a race. It has very low resolution, to the point of being barely recognizable.<br />
*'''exp0''', '''exp1''', '''exp2''' and '''exp3''' aren't really proper 3D shapes, but rather individual lines and polygons that make up the bits of debris seen after a crash.<br />
<br />
===Dashboard static parts (stda*.pvs)===<br />
<br />
A car dashboard is composed by a number of separate bitmaps, not of them being used by all cars:<br />
<br />
*'''!cg0''' and '''!eg0''' are alternative palettes for non-VGA graphic modes.<br />
*'''dash''' is the base panel of the dashboard, covering most of its drawn area.<br />
*'''dast''' complements the top of the dash bitmap with curved areas, as seen on the [[Porsche March Indy|Indy]] for instance. Since all bitmap resources correspond, naturally, to rectangular areas, there's an additional bitmap, '''dasm''', which acts as an alpha mask in order to have the proper looks of a curved surface instead of a rectangular block.<br />
*'''roof''' is the strip seen atop above the windshield for a number of cars - for instance, the ones containing "PORSCHE" or "JAGUAR" inscriptions on the [[IMSA]] cars.<br />
*'''whl2''' is the centered steering wheel bitmap. The internal pixel coordinates of it are used to define steering wheel dot positions in the car*.res.<br />
*'''whl1''' and '''whl3''' are graphics for the wheel steered left and right respectively.<br />
*'''ins2''' corresponds to the meters - tachometer and/or analog speedometer. Although the bitmap itself is redundant for all default cars, since the meter graphics are included in dash as well, ins2 has an actual purpose: define the internal coordinates for speedometer/tachometer needle render, controlled by car*.res.<br />
*'''ins1''' and '''ins3''' are complementary graphics corresponding to small sections of the dashboard uncovered when the wheel is steered left or right (and so they are complementary to whl1 and whl3, in that order). Since the images are not rectangular, alpha masks '''inm1''' and '''inm3''' are needed, just like dasm was for dast.<br />
*'''gbox''' is the shifting stick base. Coordinates for shifting knob positions are defined within the reference frame of this bitmap.<br />
<br />
===Dashboard moving parts (stdb*.pvs)=== <br />
<br />
The stdb*.pvs file contains a few auxiliary bitmaps that are not rendered all the time or change position within the screen often: <br />
<br />
*'''!cg0''' and '''!eg0''' are alternative palettes for non-VGA graphic modes.<br />
*'''dot ''' is the blue steering wheel dot. As every non-rectangular bitmap, it calls for an alpha mask, in this case called '''dota'''.<br />
*'''dot1''' and '''dot2''' are strange versions of dot with a tiny palette-like strip inserted into its top. Their purpose is currently unknown.<br />
*'''gnob''' is the shifting gear knob, and '''gnab''', its alpha mask.<br />
*From '''dig0''' to '''dig9''' there are individually-stored digits for Corvette-style digital speedometers. Their rendering is not completely straightforward, as those digits do not are not placed over the dashboard as a rectangular block and yet there are no alpha masks. <br />
<br />
All the dashboard moving parts are positioned according to various car*.res parameters, as described in the [[Car parameters#Dashboard controls|Car parameters]] article. The vector-drawn speedometer and tachometer needles are controlled by car*.res as well.<br />
<br />
===Editing and combining car graphics===<br />
<br />
Graphic files of different cars are independent, and thus can be mixed freely when constructing a new car. The main point of concern when doing so usually is adjusting car*.res so that moving parts of the dashboard behave properly. The classical example of this mix-and-match approach is [[Alan Rotoi]]'s famous [[Melange]].<br />
The actual edition of the graphics was a long-standing goal of the community that for many years was deemed impossible due the lack of information about the format employed by the developers to compress the files. In March 2008, this riddle was finally solved by [[dstien]], and since then perspectives for modding became extremely interesting (see [[Car files#Tools|Tools]] section further down the article).<br />
<br />
==Car behaviour (car*.res)==<br />
<br />
All adjustable aspects of a car behaviour are stored in car*.res, a miscellaneous data resource file. It contains both physics data, such as power curves, and visual parameters, like car height in cockpit view or speedometer behaviour. Also, the file also contains the text data displayed at the car selection screen. Data in car*.res may be read and modified by any hex editor, or more conveniently by a specially-designed graphical editor (see the Tools section ahead). <br />
<br />
The function of a large fraction of car*.res hex addresses was elucidated over the years, allowing modifications of many car aspects. Here is a quick reference for those addresses, adapted from the chart available at [http://www.kalpen.de/luke/4dinfo.html#cs Lukas Loehrer's site]. A more throughout discussion on the effects and quirks of the parameters is available at [[Car parameters]]; clicking on a parameter description will lead to the corresponding entry there.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Byte offset !! Function<br />
|-<br />
| 26h || [[Car_parameters#Number_of_gears|Number of gears]]<br />
|-<br />
| 28h-29h || [[Car_parameters#Car_mass|Car mass]]<br />
|-<br />
| 2Ah-2Bh || [[Car parameters#Braking effectiveness|Braking effectiveness]]<br />
|-<br />
| 2Ch-2Dh || [[Car parameters#Idle rpm|Idle rpm]]<br />
|-<br />
| 2Eh-2Fh || [[Car parameters#Downshift rpm|Downshift rpm (auto transm.)]]<br />
|-<br />
| 30h-31h || [[Car parameters#Upshift rpm|Upshift rpm (auto transm.)]]<br />
|-<br />
| 32h-33h || [[Car parameters#Maximum rpm|Maximum rpm]]<br />
|-<br />
| 37h-41h || [[Car parameters#Gear ratios|Gear ratios (odd offsets)]]<br />
|-<br />
| 46h-5Ch || [[Car parameters#Shifting knob positions|Shifting knob positions (even offsets)]]<br />
|-<br />
| 5Dh-5Eh || [[Car parameters#Aerodynamic resistance|Aerodynamic resistance]]<br />
|-<br />
| 60h-C7h || [[Car parameters#Torque curve|Torque curve]]<br />
|-<br />
| CAh-CBh || [[Car parameters#Grip|Grip]]<br />
|-<br />
| F6h-F7h || [[Car parameters#Car height|Car height on cockpit view]]<br />
|-<br />
| 110h-14Dh || [[Car parameters#Steering wheel dot movement|Steering wheel dot movement]]<br />
|-<br />
| 14Eh-223h || [[Car parameters#Speedometer needle movement|Speedometer needle movement]]<br />
|-<br />
| 150h-159h || [[Car parameters#Digital speedometer|Digital speedometer]]<br />
|-<br />
| 224h-32Dh || [[Car parameters#Rev meter needle movement|Rev meter needle movement]]<br />
|-<br />
| 32Eh-EOF || [[Car parameters#Text data|Text data (car selection screen and high score table)]]<br />
|-<br />
|}<br />
<br />
The actual structure of car*.res consists of four resources:<br />
*'''simd''', which contains all the numerical parameters;<br />
*'''edes''', a [[Resource file format#Plain text|text resource]] containing the description displayed in the car selection screen;<br />
*'''gsna''', the 4-letter scoreboard abbreviation stored as a text resource; and<br />
*'''gnam''', the scoreboard car name.<br />
<br />
==Version compatibility==<br />
<br />
Cars that use graphic files from Stunts 1.0 do not work properly on 1.1 versions, and vice-versa. Attempting to exchange cars between versions will cause crashes in the car selection screen due to file format incompatibilities. The simpler and naturally uncompressed car*.res files may be exchanged between versions, although car performance won't be the same due to the known differences between [[Game versions|game versions]] in that respect.<br />
<br />
==Tools==<br />
<br />
The car*.res files can be read and edited by any hex-editor or text editor able to display files in hexadecimal mode - [http://hte.sourceforge.net HT] and [http://www.vim.org Vim] are examples of each case). A more convenient alternative are graphical hex-editors designed especially for Stunts car hacking. [[Mark_Nailwood|Mark Nailwood]]'s [[Car_Blaster|Car Blaster]], by far the most used of those, has resources such as tags on useful bytes and comparison between cars. Other editors include [[Caredit]] and [[Winedit]].<br />
<br />
Modified cars are not recognized in the [[RPL_Info|RPL Info]] tool, also created by [[Mark_Nailwood|Mark Nailwood]].<br />
<br />
In 2008, [[dstien]] started development of [[stuntstools]], a set of programs that allow decompression of packed resource files and manipulation of contained resources, already including ,as of now, some import and export capabilities. This landmark event had immediate impact on the possibilities for car modification - the day when we will be able to change car shapes is approaching, and at breathtaking speed...<br />
<br />
==See also==<br />
<br />
* [[Car_parameters|Car parameters]]<br><br />
* [[Car model physics]]<br><br />
* [[Cheated_cars|Cheated cars]]<br />
<br />
==External Links==<br />
<br />
*[http://code.google.com/p/stuntstools/ dstein's stuntstools Google Code project]<br />
<br />
<br />
[[Category:Driving]]<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=699Resource file format2008-04-28T00:01:09Z<p>Dstien: /* 3d shapes */ Materials link.</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple ''resources'', blocks of data that may be of various types - text, bitmaps, sounds, etc. Resources are uniquely identified within each file solely by a 4-byte name. A resource container file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span class="hlC">// Header</span><br />
<span class="hlP">uint32</span> fileLength<br />
<span class="hlP">uint16</span> numResources<br />
<br />
<span class="hlC">// Table of contents</span><br />
<span class="hlP">char</span> ids<span class="hlB">[</span>numResources<span class="hlB">][</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint32</span> offsets<span class="hlB">[</span>numResources<span class="hlB">]</span><br />
<br />
<span class="hlC">// Resource data</span><br />
<span class="hlP">char</span> data<span class="hlB">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span class="hlP">uint16</span> width<br />
<span class="hlP">uint16</span> height<br />
<span class="hlP">uint16</span> unknown1<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint8</span> unknown2<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> image<span class="hlB">[</span>width <span class="hlB">*</span> height<span class="hlB">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' internal memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression]. Images with pixel data stored as continuos horizontal lines has <tt>unknown2</tt> set to <code>{ 0x1, 0x2, 0x4, 0x8 }</code>.<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
Shapes are composed of a vertex list and a list of primitives. Primitives are basic shapes that can have different types, such as polygons or wheels. Depending on the type it contains a number of indices into the vertex list needed to draw the shape, color variations and some rendering hints. Stunts' coordinate system use 16-bit signed integers, making the resolution relative to the scale of the model. Shapes presented in the car selection screen are more detailed than in-game shapes, thus requiring larger scaling.<br />
<br />
Due to the counter header fields being stored in single bytes, the total amount of vertices and primitives are limited to 255 per shape.<br />
<br />
'''Main strcture'''<br />
<span class="hlP">uint8</span> numVertices<br />
<span class="hlP">uint8</span> numPrimitives<br />
<span class="hlP">uint8</span> numPaintJobs<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always == 0</span><br />
<br />
VERTEX vertices<span class="hlB">[</span>numVertices<span class="hlB">]</span><br />
UNKNOWN unknowns<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
PRIMITIVE primitives<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> terminate; <span class="hlC">// Always == 0</span><br />
<br />
'''Additional structures'''<br />
<span class="hlP">struct</span> VERTEX <span class="hlB">{</span><br />
<span class="hlP">int16</span> x<br />
<span class="hlP">int16</span> y<br />
<span class="hlP">int16</span> z<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> UNKNOWN <span class="hlB">{</span><br />
<span class="hlP">int8</span> data<span class="hlB">[</span><span class="hlN">8</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> PRIMITIVE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> type<br />
<span class="hlP">uint8</span> depthIndex<br />
<span class="hlP">uint8</span> materials<span class="hlB">[</span>numPaintJobs<span class="hlB">]</span><br />
<span class="hlP">uint8</span> indices<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// Size depends on type.</span><br />
<span class="hlB">}</span><br />
<br />
'''Primitive types'''<br />
{| class="wikitable"<br />
! Primitive type !! Vertex indices needed !! Description<br />
|-<br />
| 1 || 1 || Particle, 1 pixel<br />
|-<br />
| 2 || 2 || Line segment, 1 pixel width<br />
|-<br />
| 3–10 || 3–10 || Polygon, ''n'' sides<br />
|-<br />
| 11 || 2 || Sphere (center + ~(radius / 2)<br />
|-<br />
| 12 || 6 || Wheel<br />
|-<br />
| * || 0 || Ignored<br />
|}<br />
<br />
[[Image:Wheel_Primitive_Anatomy.png|200px|right|thumb|Anatomy of a wheel shape primitive.]]<br />
The first three vertices in a wheel primitive marks the center, tire radius and rim radius for the inner wheel-half facing the vehicle. The last three vertices does the same, in the same order, for the outer half of the wheel. Directions does not matter, the vertex locations are only used to measure distances. This rule applies to the sphere primitive as well.<br />
<br />
The value <tt>depthIndex</tt> in the <tt>PRIMITIVE</tt> structure is used to override the game's depth clipping in order to avoid flickering when several primitives are being drawn at the exact same depth. Higher value gives the primitive higher precedence.<br />
<br />
[[Shape materials|Materials]] are indices into a fixed, internal game structure and are assigned per-primitive. Cars can have multiple paint jobs, every primitive in the shape must set a material for each color scheme.<br />
<br />
Experimentation has revealed that <tt>UNKNOWN</tt> data at least partially controls occlusion culling on primitive level. How, and exactly which parts of this structure does what has yet to be understood.<br />
<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Shape_materials&diff=698Shape materials2008-04-27T23:58:53Z<p>Dstien: List of materials.</p>
<hr />
<div>3d shapes refers to a predefined set of materials. A material defines the appearance of a polygon with a color and a pattern. Most materials are opaque colors, while some have see-through patterns. Multiple polygons with different material patterns can be layered to achieve certain effects, such as multi-colored grilles and lights.<br />
<br />
==Materials==<br />
{| class="wikitable sortable"<br />
! # !! Pattern !! Color !! Name !! Comment<br />
|-<br />
| 0 || Opaque || <span style="color:#000000">████</span> <tt>000000</tt> || Black<br />
|-<br />
| 1 || Opaque || <span style="color:#0000A8">████</span> <tt>0000A8</tt> || Blue<br />
|-<br />
| 2 || Opaque || <span style="color:#00A800">████</span> <tt>00A800</tt> || Green<br />
|-<br />
| 3 || Opaque || <span style="color:#00A8A8">████</span> <tt>00A8A8</tt><br />
|-<br />
| 4 || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt><br />
|-<br />
| 5 || Opaque || <span style="color:#A800A8">████</span> <tt>A800A8</tt><br />
|-<br />
| 6 || Opaque || <span style="color:#A85400">████</span> <tt>A85400</tt><br />
|-<br />
| 7 || Opaque || <span style="color:#A8A8A8">████</span> <tt>A8A8A8</tt><br />
|-<br />
| 8 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt><br />
|-<br />
| 9 || Opaque || <span style="color:#5454FC">████</span> <tt>5454FC</tt><br />
|-<br />
| 10 || Opaque || <span style="color:#54FC54">████</span> <tt>54FC54</tt><br />
|-<br />
| 11 || Opaque || <span style="color:#54FCFC">████</span> <tt>54FCFC</tt><br />
|-<br />
| 12 || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt><br />
|-<br />
| 13 || Opaque || <span style="color:#FC54FC">████</span> <tt>FC54FC</tt><br />
|-<br />
| 14 || Opaque || <span style="color:#FCFC54">████</span> <tt>FCFC54</tt><br />
|-<br />
| 15 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt><br />
|-<br />
| 16 || Opaque || <span style="color:#246820">████</span> <tt>246820</tt> || Green || Grass<br />
|-<br />
| 17 || Opaque || <span style="color:#5CFCFC">████</span> <tt>5CFCFC</tt> || Cyan || Sky<br />
|-<br />
| 18 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt><br />
|-<br />
| 19 || Opaque || <span style="color:#484848">████</span> <tt>484848</tt><br />
|-<br />
| 20 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt><br />
|-<br />
| 21 || Opaque || <span style="color:#FCFC54">████</span> <tt>FCFC54</tt><br />
|-<br />
| 22 || Grate || <span style="color:#484848">▒▒▒▒</span> <tt>484848</tt><br />
|-<br />
| 23 || Grate || <span style="color:#202020">▒▒▒▒</span> <tt>202020</tt><br />
|-<br />
| 24 || Grate || <span style="color:#FCFC54">▒▒▒▒</span> <tt>FCFC54</tt><br />
|-<br />
| 25 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt><br />
|-<br />
| 26 || Opaque || <span style="color:#B48054">████</span> <tt>B48054</tt><br />
|-<br />
| 27 || Opaque || <span style="color:#CCA080">████</span> <tt>CCA080</tt><br />
|-<br />
| 28 || Opaque || <span style="color:#D8FCFC">████</span> <tt>D8FCFC</tt><br />
|-<br />
| 29 || Opaque || <span style="color:#9CFCFC">████</span> <tt>9CFCFC</tt><br />
|-<br />
| 30 || Opaque || <span style="color:#5CFCFC">████</span> <tt>5CFCFC</tt><br />
|-<br />
| 31 || Opaque || <span style="color:#E4C4AC">████</span> <tt>E4C4AC</tt><br />
|-<br />
| 32 || Opaque || <span style="color:#C0906C">████</span> <tt>C0906C</tt><br />
|-<br />
| 33 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt><br />
|-<br />
| 34 || Grate || <span style="color:#9C9CFC">▒▒▒▒</span> <tt>9C9CFC</tt><br />
|-<br />
| 35 || Opaque || <span style="color:#FC4040">████</span> <tt>FC4040</tt><br />
|-<br />
| 36 || Opaque || <span style="color:#FC7C7C">████</span> <tt>FC7C7C</tt><br />
|-<br />
| 37 || Opaque || <span style="color:#FC40FC">████</span> <tt>FC40FC</tt><br />
|-<br />
| 38 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt><br />
|-<br />
| 39 || Opaque || <span style="color:#202020">████</span> <tt>202020</tt><br />
|-<br />
| 40 || Opaque || <span style="color:#C0C0C0">████</span> <tt>C0C0C0</tt><br />
|-<br />
| 41 || Opaque || <span style="color:#00A8A8">████</span> <tt>00A8A8</tt><br />
|-<br />
| 42 || Opaque || <span style="color:#54FCFC">████</span> <tt>54FCFC</tt><br />
|-<br />
| 43 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt><br />
|-<br />
| 44 || Opaque || <span style="color:#000000">████</span> <tt>000000</tt><br />
|-<br />
| 45 || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt><br />
|-<br />
| 46 || Opaque || <span style="color:#A80000">████</span> <tt>A80000</tt><br />
|-<br />
| 47 || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt><br />
|-<br />
| 48 || Opaque || <span style="color:#00007C">████</span> <tt>00007C</tt> || Blue 1 || Car body<br />
|-<br />
| 49 || Opaque || <span style="color:#0000A8">████</span> <tt>0000A8</tt> || Blue 2 || Car body<br />
|-<br />
| 50 || Opaque || <span style="color:#0000D0">████</span> <tt>0000D0</tt> || Blue 3 || Car body<br />
|-<br />
| 51 || Opaque || <span style="color:#0004FC">████</span> <tt>0004FC</tt> || Blue 4 || Car body<br />
|-<br />
| 52 || Opaque || <span style="color:#B40000">████</span> <tt>B40000</tt> || Red 1 || Car body<br />
|-<br />
| 53 || Opaque || <span style="color:#E40000">████</span> <tt>E40000</tt> || Red 2 || Car body<br />
|-<br />
| 54 || Opaque || <span style="color:#FC2020">████</span> <tt>FC2020</tt> || Red 3 || Car body<br />
|-<br />
| 55 || Opaque || <span style="color:#FC4040">████</span> <tt>FC4040</tt> || Red 4 || Car body<br />
|-<br />
| 56 || Opaque || <span style="color:#545454">████</span> <tt>545454</tt> || Graphite 1 || Car body<br />
|-<br />
| 57 || Opaque || <span style="color:#606060">████</span> <tt>606060</tt> || Graphite 2 || Car body<br />
|-<br />
| 58 || Opaque || <span style="color:#707070">████</span> <tt>707070</tt> || Graphite 3 || Car body<br />
|-<br />
| 59 || Opaque || <span style="color:#7C7C7C">████</span> <tt>7C7C7C</tt> || Graphite 4 || Car body<br />
|-<br />
| 60 || Opaque || <span style="color:#E4D800">████</span> <tt>E4D800</tt> || Yellow 1 || Car body<br />
|-<br />
| 61 || Opaque || <span style="color:#FCF420">████</span> <tt>FCF420</tt> || Yellow 2 || Car body<br />
|-<br />
| 62 || Opaque || <span style="color:#FCF85C">████</span> <tt>FCF85C</tt> || Yellow 3 || Car body<br />
|-<br />
| 63 || Opaque || <span style="color:#FCFC9C">████</span> <tt>FCFC9C</tt> || Yellow 4 || Car body<br />
|-<br />
| 64 || Opaque || <span style="color:#009C9C">████</span> <tt>009C9C</tt> || Cyan 1 || Car body<br />
|-<br />
| 65 || Opaque || <span style="color:#00CCCC">████</span> <tt>00CCCC</tt> || Cyan 2 || Car body<br />
|-<br />
| 66 || Opaque || <span style="color:#00E4E4">████</span> <tt>00E4E4</tt> || Cyan 3 || Car body<br />
|-<br />
| 67 || Opaque || <span style="color:#40FCFC">████</span> <tt>40FCFC</tt> || Cyan 4 || Car body<br />
|-<br />
| 68 || Opaque || <span style="color:#508400">████</span> <tt>508400</tt> || Green 1 || Car body<br />
|-<br />
| 69 || Opaque || <span style="color:#74B400">████</span> <tt>74B400</tt> || Green 2 || Car body<br />
|-<br />
| 70 || Opaque || <span style="color:#90E400">████</span> <tt>90E400</tt> || Green 3 || Car body<br />
|-<br />
| 71 || Opaque || <span style="color:#A0FC00">████</span> <tt>A0FC00</tt> || Green 4 || Car body<br />
|-<br />
| 72 || Opaque || <span style="color:#440070">████</span> <tt>440070</tt> || Purple 1 || Car body<br />
|-<br />
| 73 || Opaque || <span style="color:#60009C">████</span> <tt>60009C</tt> || Purple 2 || Car body<br />
|-<br />
| 74 || Opaque || <span style="color:#8000CC">████</span> <tt>8000CC</tt> || Purple 3 || Car body<br />
|-<br />
| 75 || Opaque || <span style="color:#A800FC">████</span> <tt>A800FC</tt> || Purple 4 || Car body<br />
|-<br />
| 76 || Opaque || <span style="color:#B0B0B0">████</span> <tt>B0B0B0</tt> || Silver 1 || Car body<br />
|-<br />
| 77 || Opaque || <span style="color:#C0C0C0">████</span> <tt>C0C0C0</tt> || Silver 2 || Car body<br />
|-<br />
| 78 || Opaque || <span style="color:#CCCCCC">████</span> <tt>CCCCCC</tt> || Silver 3 || Car body<br />
|-<br />
| 79 || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt> || Silver 4 || Car body<br />
|-<br />
| 80 || Opaque || <span style="color:#6C5800">████</span> <tt>6C5800</tt> || Golden 1 || Car body<br />
|-<br />
| 81 || Opaque || <span style="color:#847400">████</span> <tt>847400</tt> || Golden 2 || Car body<br />
|-<br />
| 82 || Opaque || <span style="color:#B4A400">████</span> <tt>B4A400</tt> || Golden 3 || Car body<br />
|-<br />
| 83 || Opaque || <span style="color:#CCC000">████</span> <tt>CCC000</tt> || Golden 4 || Car body<br />
|-<br />
| 84 || Opaque || <span style="color:#700000">████</span> <tt>700000</tt> || Burgundy 1 || Car body<br />
|-<br />
| 85 || Opaque || <span style="color:#840000">████</span> <tt>840000</tt> || Burgundy 2 || Car body<br />
|-<br />
| 86 || Opaque || <span style="color:#B40000">████</span> <tt>B40000</tt> || Burgundy 3 || Car body<br />
|-<br />
| 87 || Opaque || <span style="color:#CC0000">████</span> <tt>CC0000</tt> || Burgundy 4 || Car body<br />
|-<br />
| 88 || Opaque || <span style="color:#000040">████</span> <tt>000040</tt> || Violet 1 || Car body<br />
|-<br />
| 89 || Opaque || <span style="color:#280040">████</span> <tt>280040</tt> || Violet 2 || Car body<br />
|-<br />
| 90 || Opaque || <span style="color:#340058">████</span> <tt>340058</tt> || Violet 3 || Car body<br />
|-<br />
| 91 || Opaque || <span style="color:#500084">████</span> <tt>500084</tt> || Violet 4 || Car body<br />
|-<br />
| 92 || Opaque || <span style="color:#383838">████</span> <tt>383838</tt><br />
|-<br />
| 93 || Opaque || <span style="color:#484848">████</span> <tt>484848</tt><br />
|-<br />
| 94 || Grate || <span style="color:#CCCCCC">▒▒▒▒</span> <tt>CCCCCC</tt> || || Tennis net<br />
|-<br />
| 95 || Opaque || <span style="color:#74B400">████</span> <tt>74B400</tt> || || Tennis grass<br />
|-<br />
| 96 || Opaque || <span style="color:#FCFCFC">████</span> <tt>FCFCFC</tt><br />
|-<br />
| 97 || Opaque || <span style="color:#A8A8A8">████</span> <tt>A8A8A8</tt><br />
|-<br />
| 98 || Opaque || <span style="color:#9C6438">████</span> <tt>9C6438</tt><br />
|-<br />
| 99 || Opaque || <span style="color:#C0602C">████</span> <tt>C0602C</tt><br />
|-<br />
| 100 || Opaque || <span style="color:#0080D0">████</span> <tt>0080D0</tt><br />
|-<br />
| 101 || Opaque || <span style="color:#84E084">████</span> <tt>84E084</tt> || || Grass<br />
|-<br />
| 102 || Opaque || <span style="color:#70C46C">████</span> <tt>70C46C</tt> || || Grass<br />
|-<br />
| 103 || Opaque || <span style="color:#58A858">████</span> <tt>58A858</tt> || || Grass<br />
|-<br />
| 104 || Opaque || <span style="color:#509C4C">████</span> <tt>509C4C</tt> || || Grass<br />
|-<br />
| 105 || Opaque || <span style="color:#388034">████</span> <tt>388034</tt> || || Grass<br />
|-<br />
| 106 || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt><br />
|-<br />
| 107 || Opaque || <span style="color:#B0B0B0">████</span> <tt>B0B0B0</tt><br />
|-<br />
| 108 || Opaque || <span style="color:#905410">████</span> <tt>905410</tt><br />
|-<br />
| 109 || Opaque || <span style="color:#6C5800">████</span> <tt>6C5800</tt><br />
|-<br />
| 110 || Opaque || <span style="color:#580000">████</span> <tt>580000</tt><br />
|-<br />
| 111 || Opaque || <span style="color:#744008">████</span> <tt>744008</tt><br />
|-<br />
| 112 || Opaque || <span style="color:#700000">████</span> <tt>700000</tt><br />
|-<br />
| 113 || Opaque || <span style="color:#80542C">████</span> <tt>80542C</tt><br />
|-<br />
| 114 || Opaque || <span style="color:#540054">████</span> <tt>540054</tt><br />
|-<br />
| 115 || Opaque || <span style="color:#A400A4">████</span> <tt>A400A4</tt><br />
|-<br />
| 116 || Opaque || <span style="color:#E000E4">████</span> <tt>E000E4</tt><br />
|-<br />
| 117 || Opaque || <span style="color:#FC5CFC">████</span> <tt>FC5CFC</tt><br />
|-<br />
| 118 || Transparent || <span style="color:#FFFFFF"></span> <tt>N/A</tt> || || Windmill animation mask<br />
|-<br />
| 119 || Grille || <span style="color:#484848">▒▒▒▒</span> <tt>484848</tt><br />
|-<br />
| 120 || Inverse grille || <span style="color:#2C2C2C">▒▒▒▒</span> <tt>2C2C2C</tt><br />
|-<br />
| 121 || Glass || <span style="color:#FCFCFC">▓▓▓▓</span> <tt>FCFCFC</tt><br />
|-<br />
| 122 || Inverse glass || <span style="color:#B0B0B0">░░░░</span> <tt>B0B0B0</tt><br />
|-<br />
| 123 || Glass || <span style="color:#FCF85C">▓▓▓▓</span> <tt>FCF85C</tt><br />
|-<br />
| 124 || Inverse glass || <span style="color:#FCAC54">░░░░</span> <tt>FCAC54</tt><br />
|-<br />
| 125 || Glass || <span style="color:#FC0000">▓▓▓▓</span> <tt>FC0000</tt><br />
|-<br />
| 126 || Inverse glass || <span style="color:#9C0000">░░░░</span> <tt>9C0000</tt><br />
|-<br />
| 127 || Opaque || <span style="color:#FC5454">████</span> <tt>FC5454</tt><br />
|-<br />
| 128 || Opaque || <span style="color:#DCDCDC">████</span> <tt>DCDCDC</tt><br />
|}<br />
<br />
==Patterns==<br />
Patterns are used as a mask when drawing the polygon akin to polygon stippling in OpenGL.<br />
<br />
<gallery widths="128px" heights="128px" perrow="3"><br />
Image:Pattern_Grille.png|Grille<br />
Image:Pattern_Glass.png|Glass (lights)<br />
Image:Pattern_Grate.png|Grate (ramps, bridges)<br />
Image:Pattern_Grille_Inverse.png|Inverse grille<br />
Image:Pattern_Glass_Inverse.png|Inverse glass<br />
</gallery></div>Dstienhttps://wiki.stunts.hu/index.php?title=File:Pattern_Glass_Inverse.png&diff=697File:Pattern Glass Inverse.png2008-04-27T23:20:46Z<p>Dstien: Inverse glass material pattern.</p>
<hr />
<div>Inverse glass material pattern.</div>Dstienhttps://wiki.stunts.hu/index.php?title=File:Pattern_Glass.png&diff=696File:Pattern Glass.png2008-04-27T23:20:15Z<p>Dstien: Glass material pattern.</p>
<hr />
<div>Glass material pattern.</div>Dstienhttps://wiki.stunts.hu/index.php?title=File:Pattern_Grille_Inverse.png&diff=695File:Pattern Grille Inverse.png2008-04-27T23:19:33Z<p>Dstien: Inverse grille material pattern.</p>
<hr />
<div>Inverse grille material pattern.</div>Dstienhttps://wiki.stunts.hu/index.php?title=File:Pattern_Grille.png&diff=694File:Pattern Grille.png2008-04-27T23:18:32Z<p>Dstien: Grille material pattern.</p>
<hr />
<div>Grille material pattern.</div>Dstienhttps://wiki.stunts.hu/index.php?title=File:Pattern_Grate.png&diff=693File:Pattern Grate.png2008-04-27T23:17:34Z<p>Dstien: Grate material pattern.</p>
<hr />
<div>Grate material pattern.</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=674Resource file format2008-04-22T18:28:12Z<p>Dstien: Accidentally removed header.</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple resources of any type, identified only by a 4-byte name. A resource file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span class="hlC">// Header</span><br />
<span class="hlP">uint32</span> fileLength<br />
<span class="hlP">uint16</span> numResources<br />
<br />
<span class="hlC">// Table of contents</span><br />
<span class="hlP">char</span> ids<span class="hlB">[</span>numResources<span class="hlB">][</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint32</span> offsets<span class="hlB">[</span>numResources<span class="hlB">]</span><br />
<br />
<span class="hlC">// Resource data</span><br />
<span class="hlP">char</span> data<span class="hlB">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span class="hlP">uint16</span> width<br />
<span class="hlP">uint16</span> height<br />
<span class="hlP">uint16</span> unknown1<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint8</span> unknown2<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> image<span class="hlB">[</span>width <span class="hlB">*</span> height<span class="hlB">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' internal memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression]. Images with pixel data stored as continuos horizontal lines has <tt>unknown2</tt> set to <code>{ 0x1, 0x2, 0x4, 0x8 }</code>.<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
Shapes are composed of a vertex list and a list of primitives. Primitives are basic shapes that can have different types, such as polygons or wheels. Depending on the type it contains a number of indices into the vertex list needed to draw the shape, color variations and some rendering hints. Stunts' coordinate system use 16-bit signed integers, making the resolution relative to the scale of the model. Shapes presented in the car selection screen are more detailed than in-game shapes, thus requiring larger scaling.<br />
<br />
Due to the counter header fields being stored in single bytes, the total amount of vertices and primitives are limited to 255 per shape.<br />
<br />
'''Main strcture'''<br />
<span class="hlP">uint8</span> numVertices<br />
<span class="hlP">uint8</span> numPrimitives<br />
<span class="hlP">uint8</span> numPaintJobs<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always == 0</span><br />
<br />
VERTEX vertices<span class="hlB">[</span>numVertices<span class="hlB">]</span><br />
UNKNOWN unknowns<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
PRIMITIVE primitives<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> terminate; <span class="hlC">// Always == 0</span><br />
<br />
'''Additional structures'''<br />
<span class="hlP">struct</span> VERTEX <span class="hlB">{</span><br />
<span class="hlP">int16</span> x<br />
<span class="hlP">int16</span> y<br />
<span class="hlP">int16</span> z<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> UNKNOWN <span class="hlB">{</span><br />
<span class="hlP">int8</span> data<span class="hlB">[</span><span class="hlN">8</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> PRIMITIVE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> type<br />
<span class="hlP">uint8</span> depthIndex<br />
<span class="hlP">uint8</span> materials<span class="hlB">[</span>numPaintJobs<span class="hlB">]</span><br />
<span class="hlP">uint8</span> indices<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// Size depends on type.</span><br />
<span class="hlB">}</span><br />
<br />
'''Primitive types'''<br />
{| class="wikitable"<br />
! Primitive type !! Vertex indices needed !! Description<br />
|-<br />
| 1 || 1 || Particle, 1 pixel<br />
|-<br />
| 2 || 2 || Line segment, 1 pixel width<br />
|-<br />
| 3–10 || 3–10 || Polygon, ''n'' sides<br />
|-<br />
| 11 || 2 || Sphere (center + ~(radius / 2)<br />
|-<br />
| 12 || 6 || Wheel<br />
|-<br />
| * || 0 || Ignored<br />
|}<br />
<br />
[[Image:Wheel_Primitive_Anatomy.png|200px|right|thumb|Anatomy of a wheel shape primitive.]]<br />
The first three vertices in a wheel primitive marks the center, tire radius and rim radius for the inner wheel-half facing the vehicle. The last three vertices does the same, in the same order, for the outer half of the wheel. Directions does not matter, the vertex locations are only used to measure distances. This rule applies to the sphere primitive as well.<br />
<br />
The value <tt>depthIndex</tt> in the <tt>PRIMITIVE</tt> structure is used to override the game's depth clipping in order to avoid flickering when several primitives are being drawn at the exact same depth. Higher value gives the primitive higher precedence.<br />
<br />
Materials are indices into a fixed, internal game structure and are assigned per-primitive. Cars can have multiple paint jobs, every primitive in the shape must set a material for each color scheme.<br />
<br />
Experimentation has revealed that <tt>UNKNOWN</tt> data at least partially controls occlusion culling on primitive level. How, and exactly which parts of this structure does what has yet to be understood.<br />
<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=673Resource file format2008-04-22T18:25:36Z<p>Dstien: /* 3d shapes */ Initial spec.</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple resources of any type, identified only by a 4-byte name. A resource file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
|-<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span class="hlC">// Header</span><br />
<span class="hlP">uint32</span> fileLength<br />
<span class="hlP">uint16</span> numResources<br />
<br />
<span class="hlC">// Table of contents</span><br />
<span class="hlP">char</span> ids<span class="hlB">[</span>numResources<span class="hlB">][</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint32</span> offsets<span class="hlB">[</span>numResources<span class="hlB">]</span><br />
<br />
<span class="hlC">// Resource data</span><br />
<span class="hlP">char</span> data<span class="hlB">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span class="hlP">uint16</span> width<br />
<span class="hlP">uint16</span> height<br />
<span class="hlP">uint16</span> unknown1<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint8</span> unknown2<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> image<span class="hlB">[</span>width <span class="hlB">*</span> height<span class="hlB">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' internal memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression]. Images with pixel data stored as continuos horizontal lines has <tt>unknown2</tt> set to <code>{ 0x1, 0x2, 0x4, 0x8 }</code>.<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
Shapes are composed of a vertex list and a list of primitives. Primitives are basic shapes that can have different types, such as polygons or wheels. Depending on the type it contains a number of indices into the vertex list needed to draw the shape, color variations and some rendering hints. Stunts' coordinate system use 16-bit signed integers, making the resolution relative to the scale of the model. Shapes presented in the car selection screen are more detailed than in-game shapes, thus requiring larger scaling.<br />
<br />
Due to the counter header fields being stored in single bytes, the total amount of vertices and primitives are limited to 255 per shape.<br />
<br />
'''Main strcture'''<br />
<span class="hlP">uint8</span> numVertices<br />
<span class="hlP">uint8</span> numPrimitives<br />
<span class="hlP">uint8</span> numPaintJobs<br />
<span class="hlP">uint8</span> reserved <span class="hlC">// Always == 0</span><br />
<br />
VERTEX vertices<span class="hlB">[</span>numVertices<span class="hlB">]</span><br />
UNKNOWN unknowns<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
PRIMITIVE primitives<span class="hlB">[</span>numPrimitives<span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> terminate; <span class="hlC">// Always == 0</span><br />
<br />
'''Additional structures'''<br />
<span class="hlP">struct</span> VERTEX <span class="hlB">{</span><br />
<span class="hlP">int16</span> x<br />
<span class="hlP">int16</span> y<br />
<span class="hlP">int16</span> z<br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> UNKNOWN <span class="hlB">{</span><br />
<span class="hlP">int8</span> data<span class="hlB">[</span><span class="hlN">8</span><span class="hlB">]</span><br />
<span class="hlB">}</span><br />
<br />
<span class="hlP">struct</span> PRIMITIVE <span class="hlB">{</span><br />
<span class="hlP">uint8</span> type<br />
<span class="hlP">uint8</span> depthIndex<br />
<span class="hlP">uint8</span> materials<span class="hlB">[</span>numPaintJobs<span class="hlB">]</span><br />
<span class="hlP">uint8</span> indices<span class="hlB">[</span><span class="hlC">...</span><span class="hlB">]</span> <span class="hlC">// Size depends on type.</span><br />
<span class="hlB">}</span><br />
<br />
'''Primitive types'''<br />
{| class="wikitable"<br />
! Primitive type !! Vertex indices needed !! Description<br />
|-<br />
| 1 || 1 || Particle, 1 pixel<br />
|-<br />
| 2 || 2 || Line segment, 1 pixel width<br />
|-<br />
| 3–10 || 3–10 || Polygon, ''n'' sides<br />
|-<br />
| 11 || 2 || Sphere (center + ~(radius / 2)<br />
|-<br />
| 12 || 6 || Wheel<br />
|-<br />
| * || 0 || Ignored<br />
|}<br />
<br />
[[Image:Wheel_Primitive_Anatomy.png|200px|right|thumb|Anatomy of a wheel shape primitive.]]<br />
The first three vertices in a wheel primitive marks the center, tire radius and rim radius for the inner wheel-half facing the vehicle. The last three vertices does the same, in the same order, for the outer half of the wheel. Directions does not matter, the vertex locations are only used to measure distances. This rule applies to the sphere primitive as well.<br />
<br />
The value <tt>depthIndex</tt> in the <tt>PRIMITIVE</tt> structure is used to override the game's depth clipping in order to avoid flickering when several primitives are being drawn at the exact same depth. Higher value gives the primitive higher precedence.<br />
<br />
Materials are indices into a fixed, internal game structure and are assigned per-primitive. Cars can have multiple paint jobs, every primitive in the shape must set a material for each color scheme.<br />
<br />
Experimentation has revealed that <tt>UNKNOWN</tt> data at least partially controls occlusion culling on primitive level. How, and exactly which parts of this structure does what has yet to be understood.<br />
<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=File:Wheel_Primitive_Anatomy.png&diff=672File:Wheel Primitive Anatomy.png2008-04-22T17:37:59Z<p>Dstien: Anatomy of a wheel shape primitive.</p>
<hr />
<div>Anatomy of a wheel shape primitive.</div>Dstienhttps://wiki.stunts.hu/index.php?title=UnskilledStunts&diff=671UnskilledStunts2008-04-22T14:33:49Z<p>Dstien: /* Lead */ grown → grew</p>
<hr />
<div>'''UnskilledStunts''' was a competition managed by [[CTG]]. Started in 2003, it grew in status over the years to eventually being regarded as the second biggest full-season contest, after [[ZakStunts]]. After five complete seasons, the contest was ended by its manager in March 2008.<br />
<br />
== Season podiums ==<br />
<br />
{| style="padding:0.5em; margin:1em; width: 10cm; text-align: left; background:#fafafa; border:1px solid grey"<br />
|+ '''Season 2003'''<br />
|-<br />
|- bgcolor="#e9e9e9"<br />
! style="width:10%" | Rank<br />
! style="width:30%" | Racer<br />
! style="width:30%" | Team<br />
! style="width:10%" | Points<br />
|-<br />
| bgcolor="#d4af37"|1<br />
| [[Bonzai Joe]]<br />
| [[Cork's Crew]]<br />
| 104<br />
|-<br />
||*<br />
| [[CTG]]<br />
| [[Unskilled Drivers]]<br />
| 94<br />
|-<br />
| bgcolor="#c0c0c0"|2<br />
| [[Alain]]<br />
| [[Orion]]<br />
| 83<br />
|-<br />
| bgcolor="#cd7f32"|3<br />
| [[Krys Toff]]<br />
| [[Orion]]<br />
| 57<br />
|-<br />
|}<br />
<br />
{| style="padding:0.5em; margin:1em; width: 10cm; text-align: left; background:#fafafa; border:1px solid grey"<br />
|+ '''Season 2004/2005'''<br />
|-<br />
|- bgcolor="#e9e9e9"<br />
! style="width:10%" | Rank<br />
! style="width:30%" | Racer<br />
! style="width:30%" | Team<br />
! style="width:10%" | Points<br />
|-<br />
| bgcolor="#d4af37"|1<br />
| [[Gutix]]<br />
| [[Meganium Aces High]]<br />
| 163<br />
|-<br />
| bgcolor="#c0c0c0"|2<br />
| [[Akoss Poo]]<br />
| [[Looping Warriors]]<br />
| 122<br />
|-<br />
||*<br />
| [[CTG]]<br />
| [[Damage Inc]]<br />
| 106<br />
|-<br />
| bgcolor="#cd7f32"|3<br />
| [[Krys Toff]]<br />
| [[Damage Inc]]<br />
| 77<br />
|-<br />
|}<br />
<br />
{| style="padding:0.5em; margin:1em; width: 10cm; text-align: left; background:#fafafa; border:1px solid grey"<br />
|+ '''Season 2005/2006'''<br />
|-<br />
|- bgcolor="#e9e9e9"<br />
! style="width:10%" | Rank<br />
! style="width:30%" | Racer<br />
! style="width:30%" | Team<br />
! style="width:10%" | Points<br />
|-<br />
||*<br />
| [[CTG]]<br />
| [[Cork's Crew]]<br />
| 121<br />
|-<br />
| bgcolor="#d4af37"|1<br />
| [[Dottore]]<br />
| [[Damage Inc]]<br />
| 98<br />
|-<br />
| bgcolor="#c0c0c0"|2<br />
| [[Krys Toff]]<br />
| [[Damage Inc]]<br />
| 74<br />
|-<br />
| bgcolor="#cd7f32"|3<br />
| [[Navras]]<br />
| [[Silver Spirit]]<br />
| 68<br />
|-<br />
|} <br />
<br />
{| style="padding:0.5em; margin:1em; width: 10cm; text-align: left; background:#fafafa; border:1px solid grey"<br />
|+ '''Season 2006/2007'''<br />
|-<br />
|- bgcolor="#e9e9e9"<br />
! style="width:10%" | Rank<br />
! style="width:30%" | Racer<br />
! style="width:30%" | Team<br />
! style="width:10%" | Points<br />
|-<br />
| bgcolor="#d4af37"|1<br />
| [[Dottore]]<br />
| [[Silver Spirit]]<br />
| 134<br />
|-<br />
||*<br />
| [[CTG]]<br />
| [[Looping Warriors]]<br />
| 134<br />
|-<br />
| bgcolor="#c0c0c0"|2<br />
| [[Krys Toff]]<br />
| [[Damage Inc]]<br />
| 84<br />
|-<br />
| bgcolor="#cd7f32"|3<br />
| [[Navras]]<br />
| [[Silver Spirit]]<br />
| 84<br />
|-<br />
|}<br />
<br />
{| style="padding:0.5em; margin:1em; width: 10cm; text-align: left; background:#fafafa; border:1px solid grey"<br />
|+ '''Season 2007/2008'''<br />
|-<br />
|- bgcolor="#e9e9e9"<br />
! style="width:10%" | Rank<br />
! style="width:30%" | Racer<br />
! style="width:30%" | Team<br />
! style="width:10%" | Points<br />
|-<br />
| bgcolor="#d4af37"|1<br />
| [[Dottore]]<br />
| [[Silver Spirit]]<br />
| 129<br />
|-<br />
||*<br />
| [[CTG]]<br />
| [[Looping Warriors]]<br />
| 114<br />
|-<br />
| bgcolor="#c0c0c0"|2<br />
| [[Mark L. Rivers]]<br />
| [[-]]<br />
| 105<br />
|-<br />
| bgcolor="#cd7f32"|3<br />
| [[Navras]]<br />
| [[Silver Spirit]]<br />
| 98<br />
|-<br />
|}<br />
<br />
* - Manager results were excluded from final season standings<br />
<br />
== Medal table ==<br />
<br />
{| style="padding:0.5em; margin:1em; width: 10cm; text-align: left; background:#fafafa; border:1px solid grey"<br />
|- bgcolor="#e9e9e9"<br />
! style="width:10%" | Rank<br />
! style="width:25%" | Racer<br />
! style="width:15%" bgcolor="#d4af37"| 1st<br />
! style="width:15%" bgcolor="#c0c0c0"| 2nd<br />
! style="width:15%" bgcolor="#cd7f32"| 3rd<br />
|-<br />
| 1<br />
| [[CTG]]<br />
| 10<br />
| 12<br />
| 16<br />
|-<br />
| 2<br />
| [[Gutix]]<br />
| 9<br />
| 3<br />
| 3<br />
|-<br />
| 3<br />
| [[Dottore]]<br />
| 8<br />
| 10<br />
| 4<br />
|-<br />
| 4<br />
| [[Bonzai Joe]]<br />
| 7<br />
| 2<br />
| 5<br />
|-<br />
| 5<br />
| [[Alain]]<br />
| 5<br />
| 0<br />
| 1<br />
|-<br />
| 6<br />
| [[Akoss Poo]]<br />
| 3<br />
| 8<br />
| 2<br />
|-<br />
| 7<br />
| [[Krys Toff]]<br />
| 2<br />
| 5<br />
| 5<br />
|-<br />
| 8<br />
| [[Renato Biker]]<br />
| 2<br />
| 3<br />
| 2<br />
|-<br />
| 9<br />
| [[Argammon]]<br />
| 2<br />
| 3<br />
| 0<br />
|-<br />
| 10<br />
| [[Navras]]<br />
| 2<br />
| 2<br />
| 4<br />
|-<br />
| 11<br />
| [[Usrin]]<br />
| 2<br />
| 2<br />
| 3<br />
|-<br />
| 12<br />
| [[Mark L. Rivers]]<br />
| 2<br />
| 2<br />
| 2<br />
|-<br />
| 13<br />
| [[Duplode]]<br />
| 2<br />
| 0<br />
| 0<br />
|-<br />
| 14<br />
| [[Mingva]]<br />
| 1<br />
| 2<br />
| 0<br />
|-<br />
| 15<br />
| [[Dark Chaser]]<br />
| 1<br />
| 0<br />
| 1<br />
|-<br />
| 16<br />
| [[Chulk]]<br />
| 0<br />
| 2<br />
| 1<br />
|-<br />
| 17<br />
| [[Ayrton]]<br />
| 0<br />
| 1<br />
| 1<br />
|-<br />
| 18<br />
| [[Zweigelt]]<br />
| 0<br />
| 1<br />
| 0<br />
|-<br />
| 19<br />
| [[Alan Rotoi]]<br />
| 0<br />
| 0<br />
| 3<br />
|-<br />
| 20<br />
| [[Diesel Joe]]<br />
| 0<br />
| 0<br />
| 2<br />
|-<br />
| 21<br />
| [[FloFlo81]]<br />
| 0<br />
| 0<br />
| 1<br />
|-<br />
|}<br />
<br />
== Hall of fame: greatest UnskilledStunts replays ever ==<br />
<br />
<br />
<youtube>ms0RcmhXFY0</youtube><br />
<br />
Alain il Professore, Eger, May 2003<br />
<br />
<br />
== Related competitions ==<br />
<br />
* [[Unskilled_Stunts_League|Unskilled Stunts League]]<br><br />
* [[Unskilled_Stunts_Rapid|Unskilled Stunts Rapid]]<br />
<br />
<br />
[[Category:Competition]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=668Resource file format2008-04-22T12:11:36Z<p>Dstien: Pseudo code styling and additional info on "unknown2" in bitmap struct</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple resources of any type, identified only by a 4-byte name. A resource file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
|-<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span class="hlC">// Header</span><br />
<span class="hlP">uint32</span> fileLength<br />
<span class="hlP">uint16</span> numResources<br />
<br />
<span class="hlC">// Table of contents</span><br />
<span class="hlP">char</span> ids<span class="hlB">[</span>numResources<span class="hlB">][</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint32</span> offsets<span class="hlB">[</span>numResources<span class="hlB">]</span><br />
<br />
<span class="hlC">// Resource data</span><br />
<span class="hlP">char</span> data<span class="hlB">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span class="hlP">uint16</span> width<br />
<span class="hlP">uint16</span> height<br />
<span class="hlP">uint16</span> unknown1<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<span class="hlP">uint8</span> unknown2<span class="hlB">[</span><span class="hlN">4</span><span class="hlB">]</span><br />
<br />
<span class="hlP">uint8</span> image<span class="hlB">[</span>width <span class="hlB">*</span> height<span class="hlB">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' internal memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression]. Images with pixel data stored as continuos horizontal lines has <tt>unknown2</tt> set to <code>{ 0x1, 0x2, 0x4, 0x8 }</code>.<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=MediaWiki:Common.css&diff=667MediaWiki:Common.css2008-04-22T11:35:45Z<p>Dstien: Added syntax highlighting classes</p>
<hr />
<div>/* <pre><nowiki> */<br />
<br />
/** CSS placed here will be applied to all skins */<br />
<br />
/* wikitable class */<br />
table.wikitable {<br />
margin: 1em;<br />
padding: 0.5em;<br />
background: #fafafa;<br />
border: 1px solid gray;<br />
color: black;<br />
text-align: left;<br />
}<br />
<br />
table.wikitable th,<br />
table.wikitable td {<br />
padding-right: 1em;<br />
}<br />
<br />
table.wikitable th {<br />
background: #e9e9e9;<br />
color: black;<br />
}<br />
<br />
/* Pseudo code syntax highlighting classes */<br />
.hlC { color: #777; font-style: italic } /* Comment */<br />
.hlP { color: #933 } /* Primitive type */<br />
.hlB { color: #6c6 } /* Bracket/operator */<br />
.hlN { color: #c6c } /* Numeric */<br />
.hlS { color: #f00 } /* String */<br />
<br />
/* </nowiki></pre> */</div>Dstienhttps://wiki.stunts.hu/index.php?title=Car_files&diff=666Car files2008-04-22T11:00:52Z<p>Dstien: /* Car behaviour (car*.res) */ Table styling</p>
<hr />
<div>Stunts cars are made of four different [[Resource file format|resource files]]: st*.p3s, stda*.pvs, stdb*.pvs and car*.res ; where the * stands for an arbitrary 4-letter abbreviation shared by files of the same car. All of the car graphics are stored in the .p3s and .pvs files. The car*.res, which is the one of most concern when creating a [[Cheated Cars|tuned car]], contains numerical and text parameters, including data about car performance. <br />
<br />
==Graphics files (.p3s/.pvs)==<br />
<br />
Different aspects of a car's appearance are stored in each of the graphic file:<br />
<br />
*'''st*.p3s''' - [[Resource file format#3d shapes|3d shape resource]] file that stores the graphical 3D model of the car, including its colour data.<br />
*'''stda*.p3s''' - [[Resource file format#Bitmap images|Bitmap resource]] file that contains the dashboard image, including the shifting stick's base. Movement of tachometer, speedometer and steering wheel dot is controlled by car*.res parameters.<br />
*'''stdb*.p3s''' - [[Resource file format#Bitmap images|Bitmap resource]] file that contains the shifting knob. For the [[Corvette ZR1|Corvette]], it also stores the digital speedometer graphics.<br />
<br />
Graphic files of different cars can be mixed freely when constructing a new car (note that the car*.res may require adjustment so that the indicators work properly on a new dashboard). As for modification of the graphics themselves, until recently that was deemed impossible, for the lack of information about the format employed by the developers to compress the vector graphics. This first major obstacle, however, has been sorted out. (see [[Car files#Tools|Tools]] section below)<br />
<br />
==Car behaviour (car*.res)==<br />
<br />
All adjustable aspects of a car behaviour are stored in car*.res. Those include both physics data, such as power curves, and visual parameters, like car height in cockpit view or speedometer behaviour. Also, the file also contains the text data displayed at the car selection screen. Data in car*.res may be read and modified by any hex editor, or more conveniently by a specially-designed graphical editor (see the Tools section ahead). <br />
<br />
The function of a large fraction of car*.res hex addreses was elucidated over the years, allowing modifications of many car aspects. Here is a quick reference for those addresses, adapted from the chart available at [http://www.kalpen.de/luke/4dinfo.html#cs Lukas Loehrer's site]. A more throughout discussion on the effects and quirks of the parameters is available at [[Car parameters]]; clicking on a parameter description will lead to the corresponding entry there.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Byte offset !! Function<br />
|-<br />
| 26h || [[Car_parameters#Number_of_gears|Number of gears]]<br />
|-<br />
| 28h-29h || [[Car_parameters#Car_mass|Car mass]]<br />
|-<br />
| 2Ah-2Bh || [[Car parameters#Braking effectiveness|Braking effectiveness]]<br />
|-<br />
| 2Ch-2Dh || [[Car parameters#Idle rpm|Idle rpm]]<br />
|-<br />
| 2Eh-2Fh || [[Car parameters#Downshift rpm|Downshift rpm (auto transm.)]]<br />
|-<br />
| 30h-31h || [[Car parameters#Upshift rpm|Upshift rpm (auto transm.)]]<br />
|-<br />
| 32h-33h || [[Car parameters#Maximum rpm|Maximum rpm]]<br />
|-<br />
| 37h-41h || [[Car parameters#Gear ratios|Gear ratios (odd offsets)]]<br />
|-<br />
| 46h-5Ch || [[Car parameters#Shifting knob positions|Shifting knob positions (even offsets)]]<br />
|-<br />
| 5Dh-5Eh || [[Car parameters#Aerodynamic resistance|Aerodynamic resistance]]<br />
|-<br />
| 60h-C7h || [[Car parameters#Torque curve|Torque curve]]<br />
|-<br />
| CAh-CBh || [[Car parameters#Grip|Grip]]<br />
|-<br />
| F6h-F7h || [[Car parameters#Car height|Car height on cockpit view]]<br />
|-<br />
| 110h-14Dh || [[Car parameters#Steering wheel dot movement|Steering wheel dot movement]]<br />
|-<br />
| 14Eh-223h || [[Car parameters#Speedometer needle movement|Speedometer needle movement]]<br />
|-<br />
| 150h-159h || [[Car parameters#Digital speedometer|Digital speedometer]]<br />
|-<br />
| 224h-32Dh || [[Car parameters#Rev meter needle movement|Rev meter needle movement]]<br />
|-<br />
| 32Eh-EOF || [[Car parameters#Text data|Text data (car selection screen and high score table)]]<br />
|-<br />
|}<br />
<br />
==Version compatibility==<br />
<br />
Cars that use graphic files from Stunts 1.0 do not work properly on 1.1 versions, and vice-versa. Doing so causes a crash in the car selection screen. Although the car*.res files may be exchanged between versions, car performance won't be the same due to the known differences between [[Game versions|game versions]] in that respect.<br />
<br />
==Tools==<br />
<br />
The car*.res files can be read and edited by any hex-editor or text editor able to display files in hexadecimal mode - [http://hte.sourceforge.net HT] and [http://www.vim.org Vim] are examples of each case). A more convenient alternative are graphical hex-editors designed especially for Stunts car hacking. [[Mark_Nailwood|Mark Nailwood]]'s [[Car_Blaster|Car Blaster]], by far the most used of those, has resources such as tags on useful bytes and comparison between cars. Other editors include [[Caredit]] and [[Winedit]].<br />
<br />
Modified cars are not recognized in the [[RPL_Info|RPL Info]] tool, also created by [[Mark_Nailwood|Mark Nailwood]].<br />
<br />
In 2008, [[dstien]] created a tool named [[stunpack]] to unpack some files of the game. His project is registered here [http://code.google.com/p/stuntstools/] and is still under development, but it looks really promising. the day when we will be able to change car shapes is approaching.<br />
<br />
==See also==<br />
<br />
* [[Car_parameters|Car parameters]]<br><br />
* [[Car model physics]]<br><br />
* [[Cheated_cars|Cheated cars]]<br />
<br />
<br />
[[Category:Driving]]<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=665Resource file format2008-04-22T10:53:57Z<p>Dstien: /* File names */ Table styling</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple resources of any type, identified only by a 4-byte name. A resource file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| class="wikitable"<br />
|-<br />
! File contents !! Raw !! Compressed !! Preferred<br />
|-<br />
| Text and misc. settings || RES || PRE || Raw<br />
|-<br />
| Bitmap images || VSH || PVS || Compressed<br />
|-<br />
| Icons || ESH || PES || Compressed<br />
|-<br />
| 3d shapes || 3SH || P3S || Compressed<br />
|-<br />
| Music tracks || KMS || PKM || Raw<br />
|-<br />
| Instrument samples || VCE || PVC || Raw<br />
|-<br />
| Sound effects || SFX || PSF || Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span style="color:#777; font-style: italic">// Header</span><br />
<span style="color:#933">uint32</span> fileLength<br />
<span style="color:#933">uint16</span> numResources<br />
<br />
<span style="color:#777; font-style: italic">// Table of contents</span><br />
<span style="color:#933">char</span> ids<span style="color:#6c6">[</span>numResources<span style="color:#6c6">][</span><span style="color:#c6c">4</span><span style="color:#6c6">]</span><br />
<span style="color:#933">uint32</span> offsets<span style="color:#6c6">[</span>numResources<span style="color:#6c6">]</span><br />
<br />
<span style="color:#777; font-style: italic">// Resource data</span><br />
<span style="color:#933">char</span> data<span style="color:#6c6">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span style="color:#933">uint16</span> width<br />
<span style="color:#933">uint16</span> height<br />
<span style="color:#933">uint16</span> unknown1<span style="color:#6c6">[</span><span style="color:#c6c">4</span><span style="color:#6c6">]</span><br />
<span style="color:#933">uint8</span> unknown2<span style="color:#6c6">[</span><span style="color:#c6c">4</span><span style="color:#6c6">]</span><br />
<br />
<span style="color:#933">uint8</span> image<span style="color:#6c6">[</span>width * height<span style="color:#6c6">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' image memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression].<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=MediaWiki:Common.css&diff=664MediaWiki:Common.css2008-04-22T10:51:36Z<p>Dstien: Added wikitable style class.</p>
<hr />
<div>/* <pre><nowiki> */<br />
<br />
/** CSS placed here will be applied to all skins */<br />
<br />
/* wikitable class */<br />
table.wikitable {<br />
margin: 1em;<br />
padding: 0.5em;<br />
background: #fafafa;<br />
border: 1px solid gray;<br />
color: black;<br />
text-align: left;<br />
}<br />
<br />
table.wikitable th,<br />
table.wikitable td {<br />
padding-right: 1em;<br />
}<br />
<br />
table.wikitable th {<br />
background: #e9e9e9;<br />
color: black;<br />
}<br />
<br />
/* </nowiki></pre> */</div>Dstienhttps://wiki.stunts.hu/index.php?title=Resource_file_format&diff=655Resource file format2008-04-21T19:27:41Z<p>Dstien: Syntax highlighting.</p>
<hr />
<div>Stunts game data are stored in a common container format. Files of this format can hold multiple resources of any type, identified only by a 4-byte name. A resource file can be encapsulated by [[Compression|compression]].<br />
<br />
This document focuses on [[Game versions#PC versions|BB Stunts 1.1]], but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.<br />
<br />
==File names==<br />
Different file name extensions are used to indicate the content of the files. Compressed files has ''"P"'' (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.<br />
<br />
{| style="padding:0.5em; margin:1em; width: 40%; text-align: left; background:#fafafa; border:1px solid grey"<br />
|- bgcolor="#e9e9e9"<br />
! style="width:40%" | File contents<br />
! style="width:20%" | Raw<br />
! style="width:20%" | Compressed<br />
! style="width:20%" | Preferred<br />
|-<br />
| Text and misc. settings<br />
| RES<br />
| PRE<br />
| Raw<br />
|-<br />
| Bitmap images<br />
| VSH<br />
| PVS<br />
| Compressed<br />
|-<br />
| Icons<br />
| ESH<br />
| PES<br />
| Compressed<br />
|-<br />
| 3d shapes<br />
| 3SH<br />
| P3S<br />
| Compressed<br />
|-<br />
| Music tracks<br />
| KMS<br />
| PKM<br />
| Raw<br />
|-<br />
| Instrument samples<br />
| VCE<br />
| PVC<br />
| Raw<br />
|-<br />
| Sound effects<br />
| SFX<br />
| PSF<br />
| Raw<br />
|}<br />
<br />
==Structure==<br />
<br />
The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.<br />
<br />
<span style="color:#777; font-style: italic">// Header</span><br />
<span style="color:#933">uint32</span> fileLength<br />
<span style="color:#933">uint16</span> numResources<br />
<br />
<span style="color:#777; font-style: italic">// Table of contents</span><br />
<span style="color:#933">char</span> ids<span style="color:#6c6">[</span>numResources<span style="color:#6c6">][</span><span style="color:#c6c">4</span><span style="color:#6c6">]</span><br />
<span style="color:#933">uint32</span> offsets<span style="color:#6c6">[</span>numResources<span style="color:#6c6">]</span><br />
<br />
<span style="color:#777; font-style: italic">// Resource data</span><br />
<span style="color:#933">char</span> data<span style="color:#6c6">[]</span><br />
<br />
==Types==<br />
Resource type can be determined by looking at the resource's id string and/or the source file name.<br />
<br />
===Plain text===<br />
Text resources are null-terminated [http://en.wikipedia.org/wiki/C_string C strings] found in <tt>RES</tt>/<tt>PRE</tt> files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the ''"]"'' (right square bracket) used to represent [http://en.wikipedia.org/wiki/Newline newline] in multi-line text.<br />
<br />
===Bitmap images===<br />
[[Image:Stunts-pal-vga.png|128px|right|thumb|VGA palette used by bitmap images. Value 255 is transparency.]]<br />
Bitmaps are images with 8-bit color depth using a [[:Image:Stunts-pal-vga.png|fixed palette]] in VGA mode. Special bitmaps using the naming scheme <tt>!cg_</tt> and <tt>!eg_</tt> provides color mapping for graphics modes with fewer available colors.<br />
<br />
<span style="color:#933">uint16</span> width<br />
<span style="color:#933">uint16</span> height<br />
<span style="color:#933">uint16</span> unknown1<span style="color:#6c6">[</span><span style="color:#c6c">4</span><span style="color:#6c6">]</span><br />
<span style="color:#933">uint8</span> unknown2<span style="color:#6c6">[</span><span style="color:#c6c">4</span><span style="color:#6c6">]</span><br />
<br />
<span style="color:#933">uint8</span> image<span style="color:#6c6">[</span>width * height<span style="color:#6c6">]</span><br />
<br />
Parts of this structure are not fully understood. <tt>unknown1</tt> appears to be related to Stunts' image memory management. <tt>unknown2</tt> seems to affect how image pixels are organized in compressed resource files, likely to gain more effective [http://en.wikipedia.org/wiki/Run-length_encoding run-length compression].<br />
<br />
{{sectstub}}<br />
<br />
===Icons===<br />
{{sectstub}}<br />
<br />
===3d shapes===<br />
{{sectstub}}<br />
<br />
===Car parameters===<br />
{{main|Car parameters}}<br />
{{sectstub}}<br />
<br />
===Opponent parameters===<br />
{{sectstub}}<br />
<br />
===Music tracks===<br />
{{sectstub}}<br />
<br />
===Instrument samples===<br />
{{sectstub}}<br />
<br />
===Sound effects===<br />
{{sectstub}}<br />
<br />
==Tools==<br />
* [[stressed]] - Stunts/4D [Sports] Driving resource editor [http://stuntstools.googlecode.com/].<br />
<br />
[[Category:Game]]</div>Dstienhttps://wiki.stunts.hu/index.php?title=User_talk:Dstien&diff=654User talk:Dstien2008-04-21T17:05:14Z<p>Dstien: Signed with template.</p>
<hr />
<div>==PC-9801 version==<br />
Wow, thanks for the addition of PC-9801 version infos DStein.<br />
Is it possible that you join the Stunts forum (http://forum.stunts.hu or http://stunts.mine.nu/forum) and we talk about it there ?<br />
I'd like to test this version and see the differences with FM Towns version.<br />
edit : I wasn't logged in, this is me, Krys Toff, that wrote this message. ;-) <small>—Preceding [[Wikipedia:Wikipedia:Signatures|unsigned]] comment added by [[User:Krys Toff|Krys Toff]] ([[User talk:Krys Toff|talk]] • [[Special:Contributions/Krys Toff|contribs]]) 11:37, 3 March 2008 (CET)</small></div>Dstienhttps://wiki.stunts.hu/index.php?title=User_talk:Zaqrack&diff=653User talk:Zaqrack2008-04-21T16:50:22Z<p>Dstien: Moved reply to thread, added new comment.</p>
<hr />
<div>==Temp sysop==<br />
Can you please grant me temporary permission to edit [[MediaWiki:Common.css]] so I can add a table styling class? As of now all tables require explicit styling to get a sane appearance. —[[User:Dstien|dstien]] 16:25, 21 April 2008 (CEST)<br />
<br />
:sure, I can give you all access as soon I find out how. If you know don't hesitate to tell, else I'll look it up tonight... <small>—Preceding [[Wikipedia:Wikipedia:Signatures|unsigned]] comment added by [[User:195.56.162.29|195.56.162.29]] ([[User talk:195.56.162.29|talk]] • [[Special:Contributions/195.56.162.29|contribs]]) 16:59, 21 April 2008 (CEST)</small><br />
<br />
::I haven't operated a MediaWiki before, but according to [http://www.mediawiki.org/wiki/Manual:User_rights_management Manual:User_rights_management] there's a web interface: [[Special:UserRights]] —[[User:Dstien|dstien]] 18:50, 21 April 2008 (CEST)</div>Dstien