Jump to content

Fabrizio Caruso

Members
  • Posts

    207
  • Joined

  • Last visited

Recent Profile Visitors

3,608 profile views

Fabrizio Caruso's Achievements

Chopper Commander

Chopper Commander (4/9)

73

Reputation

  1. Thanks/Grazie @Nop90! The penpal array was indeed confusing for me as well as Handy 0.95 which hides the Suzy bug. I am happy I got the Atari Lynx glitch sorted thanks to you. Next Atari target I need to improve is the Atari 7800, which is currently lacking real graphics in Cross-Lib. I would like to show make my games playable on the browser through a Javascript emulator as I do for some of my targets (VIC20, C64, Laser500, Laser 200, etc.). Any suggestion?
  2. Thanks everyone here! Without you I was lost. I have managed to build fixed versions of all my 8 home-brews that I have written with my Cross-Lib framework: https://github.com/Fabrizio-Caruso/CROSS-LIB/releases/tag/atari_lynx
  3. I got it to work by trial and error without fully understanding what I am doing... I delete the tile area by using black as foreground and it works: void _tgi_gfx_delete(uint8_t x, uint8_t y) { empty_spr->hpos = (x)*8; empty_spr->vpos = (y)*6; empty_spr->penpal[0] = 1; tgi_sprite(empty_spr); } void _tgi_gfx_draw(uint8_t x, uint8_t y, uint8_t tile, uint8_t color) { _tgi_gfx_delete(x, y); _tgi_tile[tile].hpos = (x)*8; _tgi_tile[tile].vpos = (y)*6; _tgi_tile[tile].penpal[0]=color; tgi_sprite(&(_tgi_tile[tile])); }
  4. @Nop90Thanks a lot! I was setting penpal[0] with wrong values that made the sprite solid and so I was getting the Suzy bug (no final pixel). @Nop90 I can use your example to get my code to display transparent sprites! Now my goal is to get a total result that looks like a solid sprite without the Suzy bug. I need to clear the 8x6 "tile". How can I do it? My background color is black. I thought I could use tgi_bar (no idea what it does behind internally) but it does not produce the desired effect. Then I could just use a transparent black block with no transparent pixels but I don't know how to do it.
  5. @LordKraken I don't understand how to have a transparent color in BPP1. You seem to say it is possible. What do you mean by "first color" ? You mean the color mapped to the "0" bits or the color 0 in the palette? If I do something like: _tgi_tile[i].sprctl0 = (unsigned char) (BPP_1 | TYPE_NORMAL | 0x07); ... _tgi_tile[i].penpal[0] = (unsigned char) 0x14; then the color mapped to 0 bit, is still not transparent.
  6. @42bs, so I am confused. I am using 1BPP and 0 is not transparent. It is solid. If it can be made transparent, I would like to know how. What I need to do is display an 8 pixel wide 6 pixel solid high rectangle with just 1 foreground color (that may change on each 8x6 block) and a common background color. Probably irrelevant here: All such rectangles are aligned on 8 pixel wide 6 pixel. So they are sort of like "tiles". If I could display transparent + 1 color sprites in 1BPP, I could clear the area first and then display what I want so that the end result looks like an 8x6 tile. I need to display all pixels and avoid the hardware bug. Do you mean I can do it in 1BPP? Could you please tell me how?
  7. Thanks @42bs, so BPP_1 has no transparent color... and with BPP1 I cannot display 8 pixels. I can do only 7 pixels or 15 pixels... In reality I don't need transparency. I would just be happy with 8 solid pixels with foreground and background color. I thought of transparency as a way to work around the hardware bug of the Suzy chip. So I have to use BPP_2, then how do I set a color to be transparent? Sorry if I ask basic questions... I have read some doc and I have not understood it. What is then penpal[0] in BPP_2 ? penpal[0] -> 00 penpal[1] -> 01 penpal[2] -> 10 penpal[3] -> 11 ? What do you mean by "don't care" ? you mean transparent ?
  8. Hi everyone, I am struggling with what I thought was a rather simple problem. I need to display something as simple as an 8 pixel wide, 6 pixel high rectangles with just 1 color to chose for the foreground and 1 common background color. Due to a bug in Suzy chip if I do this I lose the 8th pixel on each line. If I add an extra dummy byte just to display the missing pixel, I end up deleting 8 (or 7) pixels on the right of my sprite. I am using something like this, which gives me a solid background with a missing last pixel and I don't know how to force Suzy to display the missing pixel without deleting 8 pixels to the right of the sprite. _tgi_tile[i].sprctl0 = (unsigned char) (BPP_1 | TYPE_NORMAL); _tgi_tile[i].sprctl1 = (unsigned char) (LITERAL | REHV); _tgi_tile[i].sprcoll = (unsigned char) NO_COLLIDE;
  9. The binary for Stinger is not the correct one. It has corrupted tiles. The good one is here: https://github.com/Fabrizio-Caruso/CROSS-LIB/releases/download/stinger/Xstinger_atari_lynx_gfx.lnx
  10. Sorry guys if this question is a bit out of scope: Is the main branch still compatible with libti99 (https://github.com/tursilion/libti99)? On a different but still related topic, do we have any chance that at least some basic input/output routines if not all libti99 could be distributed with the compiler to make things simpler for the user?
  11. Hi everyone! How can I test the latest changes? I run git pull to pull the latest changes -> OK. Then if I rerun ./install.sh <path> it seems to be doing nothing. If before that I run cleanpatches.sh, then when I run ./install.sh I get the prompt "Reversed (or previously applied) patch detected! Assume -R? [n] y", to which I can answer y or no and in both cases I get failures.
  12. @Tursi I agree with you that the compiler itself should not depend on any ROM, as it should be possible to use it to compile for other targets. On the other hand it would be very helpful if the compiler were distributed with a very thin (optional) library and by library I mean anything. It could just be a bunch of macros and not necessarily a fully fledged pre-compiled library to link. This is what is done on nearly all other 8-bit compilers (CC65 for the 6502, Z88DK for the I8080 and Z80, CMOC for the 6809, LCC1802 for the 1802, CC6303 for the 6800/3, etc.). You get a compiler together with a little (or big in some cases) dev-kit that allows you to handle some input/output on the target machine. So that your project only depends on one devkit, which you can install in one single step. Ideally your library or a sub-set of it could be optionally distributed with the compiler as long as you are not strongly against it.
  13. There maybe multiple places as they may be scattered across different releases in my GitHub page. I can make it simpler for you. Nevertheless I would prefer to complete my current work on real graphics for the 7800 before people start playing the Atari 7800 versions because the current one look quite ugly. In theory the only way to get the most up to date versions of my game for any system is to download Cross-Lib, install the required compiler (cc65 for most MOS 6502 targets) and run: xl <game> <target> where <game> is one of these games: chase, shoot, bomber, snake, horde, verbix, shuriken, stinger and <target> can be atari, atari5200, atari7800, atari_lynx, c64, c16, vic20, zx81, c128, apple2, nes, gb (gameboy), gg (gamegear), sms, spectrum, msx, cpc, zx81, coco, coco3, dragon, mo5, to7, ti99, etc...
  14. Hi @gambler172! All the 8 games written with my Cross-Lib framework (i.e., Chase, Shoot, Bomber, Snake, Horde, Verbix, Shuriken, Stinger) can be built for the Atari 7800 and for any of the 200 systems. Currently I build the games for the Atari 7800 only using 160A tile mode (3 colors + background) and with just the default tiles provided by CC65 (which is a subset of the ASCII set). No sound support yet. So on the Atari 7800 the games will only feature 4 colors and ASCII-like graphics. The game code is the same across 200 systems. So you get the very same game but the look and feel may be different. I am working on adding real tile support (not just ASCII). It is a matter of time. More colors is more complex due to the way the Atari 7800 chip works and that fact that my abstraction layer is only tile-based (no abstract sprites, so no hardware sprites). Using 160B mode with just tiles would impose other restrictions (number of tile shapes would be too low). So I may stick to 3+1 colors. P.S.: Most of the 8 games can be built optionally also in 320A mode (monochromatic but hires). Due to memory restrictions I cannot build some of them in this mode.
  15. @RB5200 I may build a repository with up to date versions. The source of the library and sometimes the source code of the games is always updated and improved. So the ideal solution would be to build the games from source but I understand this is not practical for everyone.
×
×
  • Create New...