Zerosquare

This documentation is wrong. Encoders don't have 3 different states, they have 4 different states, They behave like a Gray code counter, incrementing for one direction of rotation, and decrementing for the other (explanation on Wikipedia) It's also explained in the Jaguar developer docs, in the section about controllers. According to this, the sequences are : Clockwise rotation is : none, right, left AND right, left. Anticlockwise rotation is : none, left, left AND right, right. Personally, my code is similar to this : { unsigned long dataJoypad; unsigned long ph0, ph1, ph0_old, ph1_old; // ph0_old and ph1_old must be initialized, and preserved between calls to the routine dataJoypad = joypads->j1; // we only manage jagpad 1 for this demonstration routine ph0 = !(dataJoypad & JOYPAD_LEFT); ph1 = !(dataJoypad & JOYPAD_RIGHT); if (ph0 ^ ph0_old ^ ph1 ^ ph1_old) { if (ph0 ^ ph1_old) { // do whatever you need to move anticlockwise } else { // do whatever you need to move clockwise } } ph0_old = ph0; ph1_old = ph1; } (I've not tested it on the Jaguar, it's possible both directions are swapped)

If you don't have an IRC client and can't/don't want to install one, you can still join the Jagware chat through a web proxy. Check the "What is Jagware ?" box at the top of this page for the details, and don't hesitate to join us

As I've posted it on AtariAge a few days ago (but it wasn't in the Jaguar forum, so may not have seen it) : Both SCPCD and me are working actively on the project. The hardware is mostly functional, the logic code is being debugged and the firmware is in the making. It's getting closer to release every day

Et un an de plus pour notre fan de SuperBurnout préféré !

It's been released.

That's correct. It is designed to be used in future homebrew games. On the other hand, including support for it in existing games may be possible if : - the source code has been recovered - there is sufficient CPU time available to run the extra code - someone takes the time to do it

Replied at FreeJag

I wrote a quick program to convert the pictures to .BMP files. The C source file is included. 8bit_to_bmp.zip So far, it seems to work OK. Here's what I get from the Alice.pic file : The program must be run from a command line, like this : 8bit_to_bmp <image file> <palette file> <output file> <image width> You have to guess which palette file is the right one (just test them all), and the width of the image. Only RGB palette files are supported at the moment. Example for converting Alice.pic : 8bit_to_bmp alice.pic bset5.rgb alice.bmp 400

Thanks Beware : upon checking, it seems that the 74HC4538 and 74HCT4538 ICs are not 100% compatible with the standard 4538. I think it could be fixed in software, but that would require an additional setting. In the meantime, I recommend against using them.

OK, after looking at it, it's definitely a 400x400 8-bit palettized image, not CRY or RGB16. However the palette is not in the .PIC file. Have you found any other files that could be it ? (i'm guessing it would be named something like "Alice.pal" and be 512 bytes long, or so).

I don't know any converter which does this. If it's only for viewing, or if you have just a few images to convert, you can use JagViewer and take screenshots. (Beware though, it seems to be a bit buggy ; the colors are slightly wrong) : JagViewer.zip If you have a lot of pictures to convert... I guess I could write a converter (I have most of the needed code already written for other projects). But it cannot be fully automatic, as there isn't any way to know the location and the size of the images in the ROM. In both cases, it won't work if the pictures are compressed in any way.

The IRC channel is currently being attacked by spambots. They can't be banned, because they use a lot of different hosts, and we don't want to ban anyone innocent by accident. To keep them out, a password has been added. It is "do_the_math" You can now join the channel by typing "/join #jagware password" Sorry for the inconvenience. EDIT : we had to change the password, it seems that the bots either "guessed" or brute-forced it.

No, the hardware only supports pure black for the transparent "color". However, if black is inconvenient when drawing (and that's often the case), you can use another color which is not used anywhere on your sprite. A common choice is pure magenta. Once your sprite is completely drawn : - use your paint program features to replace black by very dark blue - do the same thing to replace your "transparent" color by pure black Yes, it's best, as the Jaguar doesn't support alpha blending ; but it uses more memory, obviously. Another option is not to use antialiasing for your sprite's edges, but it's less pretty

Sympa Quelques p'tites remarques : - du JPG aurait suffi, ça va plus vite à charger - utiliser les images d'origine comme vignette, c'est pââââs bien - lier la vignette à la version 1:1 de l'image pour qu'on puisse cliquer dessus, c'est bien

Nice ! Cheaters

It looks even better in hi-def

As I already said on AtariAge : it looks very promising, it's impressive how quickly you developed it. and the fact that it will be free with the source is especially nice. I'm awaiting the release eagerly

Happy birthday Starcat, once again

Aucune idée, on ne l'a pas vu depuis décembre dernier...

Happy birthday to both

Once again, happy birthday to Symmetry

In a few months, if everything goes right

Thanks for the kind comments Don't worry about overheating -- thanks to the advance in technology, the chip we use generates very little heat.

Thanks