gbdk-2020 | GameBoy Development Kit |
| download: https://git.y1.nz/archives/gbdk.tar.gz | |
| README | Files | Log | Refs | LICENSE |
commit dcb3d71d44afdb1d932af9bd5536f8aacdc691b7 parent 19df6423982d584adfca63c05ac557b4a783714e Author: bbbbbr <bbbbbr@users.noreply.github.com> Date: Sat, 8 Jun 2024 00:19:08 -0700 Merge pull request #695 from bbbbbr/docs_4_3 Docs: regenerate changed docs and pdf Diffstat:
| M | docs/api/docs_faq.html | 50 | +++++++++++++++++++++++++++++++++++--------------- |
| M | docs/api/docs_migrating_versions.html | 2 | +- |
| M | docs/api/docs_releases.html | 15 | ++++++++++----- |
| M | docs/api/docs_supported_consoles.html | 38 | +++++++++++++++++++------------------- |
| M | docs/api/index.js | 2 | +- |
| M | docs/gbdk_manual.pdf | 0 | |
| M | docs/pages/09_migrating_new_versions.md | 2 | +- |
7 files changed, 67 insertions(+), 42 deletions(-)
diff --git a/docs/api/docs_faq.html b/docs/api/docs_faq.html @@ -171,6 +171,8 @@ Errors and Warnings</h1> </li> </ul> </li> +</ul> +<p><a class="anchor" id="faq_linker_conflicting_sdcc_options"></a></p><ul> <li>What does the warning <code>?ASlink-Warning-Conflicting sdcc options: "-msm83" in module "_____" and "-mgbz80" in module "_____".</code> mean?<ul> <li>One object file was compiled with the PORT setting as <code>gbz80</code> (meaning a version of SDCC / GBDK-2020 <b>OLDER than GBDK-2020 4.1.0</b>).</li> <li>The other had the PORT setting as <code>sm83</code> (meaning <b>GBDK-2020 4.1.0 or LATER</b>).</li> @@ -179,6 +181,13 @@ Errors and Warnings</h1> </ul> </li> </ul> +<p><a class="anchor" id="faq_linker_undefined_global"></a></p><ul> +<li>What does the warning <code>?ASlink-Warning-Undefined Global ...</code> mean?<ul> +<li>The linker is unable to find a variable or function that is referenced by some part of the program. This usually means a required source file is not being passed to the linker stage. Make sure all of your project source files are getting compiled and passed to the linker. <br /> +</li> +</ul> +</li> +</ul> <p><a class="anchor" id="faq_sdcc_peephole_instruction_error"></a></p><ul> <li>What does <code>z80instructionSize() failed to parse line node, assuming 999 bytes</code> mean?<ul> <li>This is a known issue with SDCC Peephole Optimizer parsing and can be ignored. A bug report has been filed for it. <br /> @@ -198,34 +207,34 @@ Errors and Warnings</h1> </li> </ul> <p><a class="anchor" id="faq_error_mbc_size"></a></p><ul> -<li>What does <code>error: size of the buffer is too small</code> mean?<ul> +<li>What do these errors mean? <code>error: size of the buffer is too small</code> <code>error: ROM is too large for number of banks specified</code><ul> <li><p class="startli">Your program is using more banks than you have configured in the toolchain. Either the MBC type was not set, or the number of banks or MBC type should be changed to provide more banks.</p> <p class="startli">See the section <a class="el" href="docs_rombanking_mbcs.html#setting_mbc_and_rom_ram_banks">setting_mbc_and_rom_ram_banks</a> for more details. <br /> </p> </li> </ul> </li> -<li>What do the following kinds of warnings / errors mean? <code>info 218: z80instructionSize() failed to parse line node, assuming 999 bytes</code><ul> -<li>This is a known issue with SDCC, it should not cause actual problems and you can ignore the warning. <br /> -</li> </ul> -</li> -<li>Why is the compiler so slow, or why did it suddenly get much slower?<ul> -<li>This may happen if you have large initialized arrays declared without the <code>const</code> keyword. It's important to use the const keyword for read-only data. See <a class="el" href="docs_coding_guidelines.html#const_gbtd_gbmb">const_gbtd_gbmb</a> and <a class="el" href="docs_coding_guidelines.html#const_array_data">const_array_data</a></li> -<li>It can also happen if C source files are <code>#included</code> into other C source files, or if there is a very large source file. <br /> -</li> -</ul> -</li> +<p><a class="anchor" id="faq_sdcc_function_declarator_missing_prototype"></a></p><ul> <li>What does <code>warning 283: function declarator with no prototype</code> mean?<ul> <li>Function forward declarations and definitions which have no arguments should be changed from <code>func()</code> to <code>func(void)</code>.</li> <li>In C <code>func()</code> and <code>func(void)</code> do not mean the same thing. <code>()</code> means any number of parameters, <code>(void)</code> means no parameters. For example if a function with no arguments is declared with <code>()</code> then there may not be an error or warning when mistakenly trying to pass arguments to it. <br /> </li> </ul> </li> -<li>What do the warnings <code>warning 126: unreachable code</code> and <code>warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG</code> mean?<ul> -<li>There is source code which the compiler has determined will never get executed based on the input values. So either a warning is omitted, or in some cases the optimizer has changed the program so that it skips code that will never run. <br /> +</ul> +<p><a class="anchor" id="faq_sdcc_unreachable_code"></a></p><ul> +<li>What do these warnings mean? <code>warning 126: unreachable code</code> <code>warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG</code><ul> +<li>The compiler is indicating that some branches of the code will never get executed or will have no effect, and so have been removed during optimization. There may be a logical error, unnecessary logic or unused variables.</li> +<li>If this is due to a variable which gets modified outside of normal execution (such as during an interrupt) then the <code>volatile</code> keyword can be added to it's declaration. This removes some optimizations and tells the compiler the variable's value may change unexpectedly and cannot be predicted only based on the surrounding code. <br /> +</li> +</ul> </li> </ul> +<p><a class="anchor" id="faq_sdcc_overflow_implicit_constant_conversion"></a></p><ul> +<li>What does this warning mean? <code>WARNING: overflow in implicit constant conversion</code><ul> +<li>See <a class="el" href="docs_coding_guidelines.html#docs_constant_signedness">Constants, Signed-ness and Overflows</a></li> +</ul> </li> </ul> <p><a class="anchor" id="faq_macos_security_warning"></a></p><ul> @@ -236,6 +245,13 @@ Errors and Warnings</h1> </ul> </li> </ul> +<p><a class="anchor" id="faq_sdcc_z80_failed_to_parse"></a></p><ul> +<li>What do the following kinds of warnings / errors mean? <code>info 218: z80instructionSize() failed to parse line node, assuming 999 bytes</code><ul> +<li>This is a known issue with SDCC, it should not cause actual problems and you can ignore the warning. <br /> +</li> +</ul> +</li> +</ul> <h1><a class="anchor" id="autotoc_md222"></a> Debugging / Compiling / Toolchain</h1> <ul> @@ -259,8 +275,12 @@ Debugging / Compiling / Toolchain</h1> </li> </ul> </li> -<li>What does this warning mean? <code>WARNING: overflow in implicit constant conversion</code><ul> -<li>See <a class="el" href="docs_coding_guidelines.html#docs_constant_signedness">Constants, Signed-ness and Overflows</a></li> +</ul> +<p><a class="anchor" id="faq_sdcc_slow_compiling"></a></p><ul> +<li>Why is the compiler so slow, or why did it suddenly get much slower?<ul> +<li>This may happen if you have large initialized arrays declared without the <code>const</code> keyword. It's important to use the const keyword for read-only data. See <a class="el" href="docs_coding_guidelines.html#const_gbtd_gbmb">const_gbtd_gbmb</a> and <a class="el" href="docs_coding_guidelines.html#const_array_data">const_array_data</a></li> +<li>It can also happen if C source files are <code>#included</code> into other C source files, or if there is a very large source file. <br /> +</li> </ul> </li> <li>Known issue: SDCC may fail on Windows when <a class="el" href="docs_getting_started.html#windows_sdcc_non_c_drive_path_spaces">run from folder names with spaces on non-C drives</a>. <br /> diff --git a/docs/api/docs_migrating_versions.html b/docs/api/docs_migrating_versions.html @@ -108,7 +108,7 @@ Porting to GBDK-2020 4.3.0</h2> <li><a class="el" href="asm_2types_8h.html#aa8480aed89a168ec484727f5ac985cd0">BANKED</a> macro instead of <code>__banked</code></li> </ul> </li> -<li><a class="el" href="msx_8h.html#a7d5ed1aed79d8fd2894893d7f6f9b835">set_sprite_palette()</a> now indexes from <code>0..3</code> instead of <code>4..7</code></li> +<li>NES <a class="el" href="msx_8h.html#a7d5ed1aed79d8fd2894893d7f6f9b835">set_sprite_palette()</a> now indexes from <code>0..3</code> instead of <code>4..7</code></li> <li>png2asset:<ul> <li>If using either <code>-bpp 1</code> or <code>-pack_mode 1bpp</code> then the other is auto-enabled</li> <li>Significant bug fixes and changes, check to make sure output is as expected</li> diff --git a/docs/api/docs_releases.html b/docs/api/docs_releases.html @@ -115,14 +115,19 @@ GBDK-2020 4.3.0</h2> <li>Changed <a class="el" href="gbdk_2emu__debug_8h.html#a910b2802e154473f2e10201f5722bc10">EMU_printf()</a> to remove dependency on stdio.h added similar <a class="el" href="gbdk_2emu__debug_8h.html#a322fb0f357e31e5f275d6c1b2c71d1e7">EMU_fmtbuf()</a></li> <li>Fixed <a class="el" href="gbdk_2emu__debug_8h.html">emu_debug.h</a> macros missing a trailing space</li> <li>NES<ul> -<li>Many library improvements</li> -<li>Added PAL support</li> +<li>Added PAL support (detects NTSC/PAL/Dendy on reset to adjust fake LCD ISR timings)</li> <li>Added BCD support</li> -<li>Added deferred hblank system for fake LCD ISRs</li> +<li>Added deferred hblank system for fake LCD ISRs, allowing for multiple splits per-frame</li> +<li>NMI optimization: Only call delay routine for remaining-vblank and LCD handler execution if LCD handler present</li> +<li>NMI optimization: Skip OAM DMA and delay routines when display is off, to increase unbuffered performance</li> +<li>NMI optimization: Save 8 cycles of stripe setup cost in vram transfer buffer execution</li> +<li>ZP memory optimization: Make gbdk-nes functions use its own dedicated overlay segment</li> <li>Fixed <code>_map_tile_offset</code> not being applied for <a class="el" href="gb_8h.html#a811c386cac0df2d260aacb5a43608be5">set_bkg_based_tiles()</a></li> <li>Fixed VRAM transfer buffer bug (ensure stack page cleared on reset)</li> <li>Fixed support for 4-player controllers using fourscore</li> <li>Fixed <a class="el" href="msx_8h.html#a7d5ed1aed79d8fd2894893d7f6f9b835">set_sprite_palette()</a> to index from <code>0..3</code> instead of <code>4..7</code></li> +<li>Fixed __move_metasprite to initialize Y index register to zero</li> +<li>Fixed <a class="el" href="sms_8h.html#aebc8751fa428e9845ea25b1060ebe772">waitpadup</a> to wait for button release instead of press</li> <li>Updated libc to latest from sdcc 4.4.0</li> </ul> </li> @@ -130,7 +135,7 @@ GBDK-2020 4.3.0</h2> <li>Added <a class="el" href="sms_8h.html#a495bc9f405f916f02ad5d97e6e730134">SHOW_SPRITES</a>, <a class="el" href="sms_8h.html#a69ef98aee664b8abd8d1a3d45f016dda">HIDE_SPRITES</a> (no hiding mid-frame)</li> <li>Added <a class="el" href="sms_8h.html#a33caf10f6d1a7cbb6bd07b899c1a545f">S_BANK</a> tile attribute</li> <li>Added 6 button controller support in <a class="el" href="gb_8h.html#a4344fefd260763e12703138066841b19">joypad()</a></li> -<li>Added <a class="el" href="sms_2bcd_8h.html">bcd.h</a> implementation</li> +<li>Added BCD support</li> <li>Added ability to move VDP SAT and name table to other locations by writing to VDP R2 and VDP R5.<ul> <li>Set name table to 0x1800 and SAT to 0x1F00 by default to free up some sprite tile space</li> <li>Added R5_SAT_0x1F00 definition for the R5 value controlling SAT position in VRAM</li> @@ -239,7 +244,7 @@ GBDK-2020 4.3.0</h2> </ul> </li> <li>Fixes for SMS/GG: Fonts, Large Map, gbdecompress</li> -<li>Fixed NES version of Text Scroller to have splits as other platforms</li> +<li>Fixed NES version of Text Scroller to have multiple splits as other platforms do</li> <li>Fixed Simple Physics: joypad input caching was wrong</li> <li>Fixed Banks Non-Intrinsic: mismatched SRAM banks for final calculation, improved naming</li> <li>Removed Analogue Pocket examples that were just duplicates of Game Boy ones</li> diff --git a/docs/api/docs_supported_consoles.html b/docs/api/docs_supported_consoles.html @@ -543,38 +543,38 @@ Buffered mode vs direct mode</h3> <p>To deal with this limitation, all functions in gbdk-nes that write to PPU memory can run in either <em>Buffered</em> or <em>Direct</em> mode.</p> <p>The good news is that switching between buffered and direct mode in gbdk-nes is usually done behind-the-scenes and normally shouldn't affect your code too much, as long as you use the portable GBDK functions and macros to do this.</p> <ul> -<li>DISPLAY_ON / SHOW_BG / SHOW_SPR will all switch the system into buffered mode, allowing limited amounts of transfers during vblank, not the display of graphics</li> +<li>DISPLAY_ON / SHOW_BG / SHOW_SPR will all switch the system into buffered mode, allowing limited amounts of transfers during vblank, without affecting the display of graphics</li> <li>DISPLAY_OFF will switch the system into direct mode, allowing much larger/faster transfers while the screen is blanked</li> </ul> <p>The following sections describe how the buffered / direct modes work in more detail. As buffered / direct mode is mostly hidden by the API calls, feel free to skip these sections if you wish.</p> <h4><a class="anchor" id="autotoc_md175"></a> Buffered mode implementation details</h4> -<p>To take maximum advantage of the short vblank period, gbdk-nes implements the same system as nearly every other NES engine: An unrolled loop that pulls prepared data bytes from the stack. </p><pre class="fragment">PLA +<p>To take maximum advantage of the short vblank period, gbdk-nes implements a popular optimization: An unrolled loop that pulls prepared data bytes from the stack. </p><pre class="fragment">PLA STA PPUDATA ... PLA STA PPUDATA RTS -</pre><p> The data structure to facilitate this is usually called a vram transfer buffer, often affectionately called a "popslide" buffer after Damian Yerrick's implementation. This buffer essentially forms a list of commands where each comand sets up a new PPU address and then writes a sequence of bytes with an auto-increment of either +1 or +32. Each such command is often called a "stripe" in the nesdev community.</p> -<p>It starts at 0x100 and takes around half of the hardware stack page. You can think of the transfer buffer as a software-implemented DMA that allows writing bytes at the optimal rate of 8 cycles / byte. (ignoring the PPU address setup cost)</p> -<p>The buffer allows writing up to 32 continuous bytes at a time. This allows updating a full screen row / column, or two 8x8 tiles worth of tile data in one command / "stripe".</p> +</pre><p> The data structure to facilitate this is usually called a vram transfer buffer, often affectionately called a "popslide" buffer after Damian Yerrick's implementation. This buffer essentially forms a list of commands where each command sets up a new PPU address and then writes a sequence of bytes with an auto-increment of either +1 or +32. Each such command is often called a "stripe" in the nesdev community.</p> +<p>The transfer buffer starts at 0x100 and takes around half of the hardware stack page. You can think of the transfer buffer as a software-implemented DMA that allows writing bytes at the optimal rate of 8 cycles / byte. (ignoring the PPU address setup cost)</p> +<p>The buffer supports writing up to 32 continuous bytes at a time. This allows updating a full screen row / column, or two 8x8 tiles worth of tile data in one command / "stripe".</p> <p>By doing writes to this buffer during game logic, your game will effectively keep writing data transfer commands for the vblank NMI handler to process in the next vblank period, without having to wait until the vblank.</p> -<p>Given that transfer buffer only has space for around 100 data bytes, it is important to not overfill the buffer, as this will bring code execution to a screeching halt, until the NMI handler empties the old contents of the buffer to free up space to allow new commands to be written.</p> +<p>Given that the transfer buffer only has space for around 100 data bytes, it is important to not overfill the buffer, as this will bring code execution to a screeching halt, until the NMI handler empties the old contents of the buffer to free up space and allow new commands to be written.</p> <p>Buffered mode is typically used for scrolling updates or dynamically animated tiles, where only a small amount of bytes need updating per frame.</p> <h4><a class="anchor" id="autotoc_md176"></a> Direct mode implementation details</h4> -<p>During direct mode, all graphics routines will write directly to the PPUADDR / PPUDATA ports and the transfer buffer limit is never a concern because the transfer buffer is effectively avoided.</p> +<p>During direct mode, all graphics routines will write directly to the PPUADDR / PPUDATA ports and the transfer buffer limit is never a concern because the transfer buffer is effectively bypassed.</p> <p>Direct mode is typically used for initializing large amounts of tile data at boot and/or level loading time. Unless you plan to have an animated loading screen and decompress a lot of data, it makes more sense to just fade the screen to black and allow direct mode to write data as fast as possible.</p> <h4><a class="anchor" id="autotoc_md177"></a> Caveat: Make sure the transfer buffer is emptied before switching to direct mode</h4> -<p>Because the switch to the direct mode is instant and doesn't wait for the next invocation of the vblank, it is possible to create situations where there is still remaining data in the transfer buffer that would only get written once the system is switched back to buffered mode.</p> -<p>To avoid this situation, make sure to always "drain" the buffer by doing a call to wait_vbl_done when you expect your code to finish.</p> +<p>Because the switch to direct mode is instant and doesn't wait for the next invocation of the vblank, it is possible to create situations where there is still remaining data in the transfer buffer that would only get written once the system is switched back to buffered mode.</p> +<p>To avoid this situation, make sure to always "drain" the buffer by doing a call to vsync when you expect your code to finish.</p> <h4><a class="anchor" id="autotoc_md178"></a> Caveat: Only update the PPU palette during buffered mode</h4> <p>The oddity that PPU palette values are accessed through the same mechanism as other PPU memory bytes comes with the side effect that the vblank NMI handler will only write the palette values in buffered mode.</p> <p>The reason for this design choice is two-fold:</p><ul> <li>Having the NMI handler keep doing the palette updates when in direct mode would result in a race condition when the NMI handler interrupts the direct mode code and messes with the PPUADDR state that the direct mode code expects to remain unchanged</li> -<li>Having the palette updates also switch to direct mode would run into another quirk of the system: Pointing PPUADDR at palette registers when display is turned off will make the display output that palette color instead of the common background color. The result would be glitchy artifacts on screen when updating the palette, leading to slightly-glitchy looking game whenever the palette is updated with the screen off</li> +<li>Having the palette updates also switch to direct mode would run into another quirk of the system: Pointing PPUADDR at palette registers when display is turned off will make the display output that palette color instead of the common background color. The result would be glitchy artifacts on screen when updating the palette, leading to a slightly-glitchy looking game whenever the palette is updated with the screen off</li> </ul> <p>To work around this, you are advised to never fully turn the display off during a palette fade. If you don't follow this advice all your palette updates will get delayed until the screen is turned back on.</p> <h3><a class="anchor" id="autotoc_md179"></a> @@ -587,28 +587,28 @@ Implementation of (fake) vbl / lcd handlers</h3> <p>GBDK provides an API for installing Interrupt Service Routines that execute on start of vblank (VBL handler), or on a specific scanline (LCD handler).</p> <p>But the base NES system has no suitable scanline interrupts that can provide such functionality. So instead, gbdk-nes API allows <em>fake</em> handlers to be installed in the goal of keeping code compatible with other platforms.</p> <ul> -<li>An installed VBL handler will be called immediately when calling wait_vbl_done. This handler should only update PPU shadow registers</li> +<li>An installed VBL handler will be called immediately when calling vsync. This handler should only update PPU shadow registers.</li> <li>An installed LCD handler for a specific scanline will then be called repeatedly until the value of _lcd_scanline is either set to an earlier scanline or >= 240. After each invocation, shadow registers are stored into a buffer.</li> <li>After the vblank NMI handler has finished palette updates, OAM DMA, VRAM updates and scroll updates it will then manually run a delay loop to reach the particular scanlines that the installed LCD handler was pre-called for, and use the contents of the buffer to update registers.</li> </ul> <p>Because the LCD "ISR" is actually implemented with a delay loop, it will burn a lot of CPU cycles in the frame - the further down the requested scanline is the larger the CPU cycle loss. In practice this makes this faked-LCD-ISR functionality mostly suitable for status bars at the top of the screen screen. Or for simple parallax cutscenes where the CPU has little else to do.</p> <dl class="section note"><dt>Note</dt><dd>The support for VBL and LCD handlers is currently under consideration and subject to change in newer versions of gbdk-nes.</dd></dl> <h3><a class="anchor" id="autotoc_md181"></a> -Caveat: Make sure to call wait_vbl_done on every frame</h3> -<p>On the GB, the call to wait_vbl_done is an optional call that serves two purposes:</p> +Caveat: Make sure to call vsync on every frame</h3> +<p>On the GB, the call to vsync is an optional call that serves two purposes:</p> <ol type="1"> <li>It provides a consistent frame timing for your game</li> <li>It allows future register writes to be synchronized to the screen</li> </ol> -<p>On gbdk-nes the second point is no longer true, because writes need to be made to the shadow registers <em>before</em> wait_vbl_done is called.</p> -<p>But the wait_vbl_done call serves three other very important purposes:</p> +<p>On gbdk-nes the second point is no longer true, because writes need to be made to the shadow registers <em>before</em> vsync is called.</p> +<p>But the vsync call serves three other very important purposes:</p> <p>A. It calls the optional VBL handler, where shadow registers can be written (and will later be picked up by the actual vblank NMI handler) B. It repeatedly calls the optional LCD handler up to MAX_LCD_ISR_CALLS times. After each call, PPU shadow registers are stored into a buffer that will later be used by timed code in the NMI to handle mid-frame changes for screen splits / sprite hiding / etc. C. It calls flush_shadow_attributes so that updates to background attributes actually get written to PPU memory</p> -<p>For these reasons you should always include a call to wait_vbl_done if you expect to see any graphical updates on the screen.</p> +<p>For these reasons you should always include a call to vsync if you expect to see any graphical updates on the screen.</p> <h3><a class="anchor" id="autotoc_md182"></a> Caveat: Do all status bar scroll movement in LCD handlers to mitigate glitches</h3> -<p>The fake LCD ISR system is not bullet-proof. In particular, it has a problem where lag frames can cause the shadow register updates in LCD handlers not to be ready in time for when the timed code in the NMI handler would be called. This will effectively cause all those updates to be missing for one frame and glitched scroll updates.</p> +<p>The fake LCD ISR system is not bullet-proof. In particular, it has a problem where lag frames can cause the shadow register updates in LCD handlers not to be ready in time for when the timed code in the NMI handler would be called. This will effectively cause all those updates to be missing for one frame, and result in glitched scroll updates.</p> <p>There is currently no complete work-around for this problem other than avoiding lag frames altogether. But the glitch can be made less distracting by making sure only the status bar glitches rather than the main background.</p> -<p>maIf you are using LCD handlers to achieve a top-screen stationary status bar, it is recommended that you follow the following guidelines to make sure the background itself has consistent scrolling:</p><ul> +<p>If you are using LCD handlers to achieve a top-screen stationary status bar, it is recommended that you follow the following guidelines to make sure the background itself has consistent scrolling:</p><ul> <li>Use move_bkg either in your main loop or in the VBL handler, to set the level scrolling</li> <li>Use move_bkg in the first invocation of the LCD handler, to set the (stationary) status bar scroll position</li> <li>Use move_bkg in the second invocation of the LCD handler, to reset the background scrolling</li> @@ -624,7 +624,7 @@ Tile and Map Data in 2bpp Game Boy Format</h4> </ul> <h4><a class="anchor" id="autotoc_md185"></a> Tile and Map Data in Native Format</h4> -<p>Use the following api calls when assets are avaialble in the native format for each platform.</p> +<p>Use the following api calls when assets are available in the native format for each platform.</p> <p><a class="el" href="gb_8h.html#a68651e50243349b48164a8ad983dca4e">set_native_tile_data()</a></p><ul> <li>GB/AP: loads 2bpp tiles data</li> <li>NES: loads 2bpp tiles data</li> diff --git a/docs/api/index.js b/docs/api/index.js @@ -191,7 +191,7 @@ var index = ] ], [ "Shadow PPU registers", "docs_supported_consoles.html#autotoc_md179", null ], [ "Implementation of (fake) vbl / lcd handlers", "docs_supported_consoles.html#autotoc_md180", null ], - [ "Caveat: Make sure to call wait_vbl_done on every frame", "docs_supported_consoles.html#autotoc_md181", null ], + [ "Caveat: Make sure to call vsync on every frame", "docs_supported_consoles.html#autotoc_md181", null ], [ "Caveat: Do all status bar scroll movement in LCD handlers to mitigate glitches", "docs_supported_consoles.html#autotoc_md182", null ], [ "Tile Data and Tile Map loading", "docs_supported_consoles.html#autotoc_md183", [ [ "Tile and Map Data in 2bpp Game Boy Format", "docs_supported_consoles.html#autotoc_md184", null ], diff --git a/docs/gbdk_manual.pdf b/docs/gbdk_manual.pdf Binary files differ. diff --git a/docs/pages/09_migrating_new_versions.md b/docs/pages/09_migrating_new_versions.md @@ -13,7 +13,7 @@ This section contains information that may be useful to know or important when u - Recommend using: - @ref CURRENT_BANK instead of `_current_bank` - @ref BANKED macro instead of `__banked` - - @ref set_sprite_palette() now indexes from `0..3` instead of `4..7` + - NES @ref set_sprite_palette() now indexes from `0..3` instead of `4..7` - png2asset: - If using either `-bpp 1` or `-pack_mode 1bpp` then the other is auto-enabled - Significant bug fixes and changes, check to make sure output is as expected
This webpage is intended to be an accessible preview of this repository. To get a fuller picture, clone it and use the git CLI.