SebRmv

I fixed a bug in the survey (or is it a bug of chrome?). I hope now everything works as expected. Sorry for the inconvenience.

Dear all, I have set up a survey in order to evaluate the demand for Another World cartridges. Please fill the form http://removers.free.fr/AnotherWorld/survey.php if you are interested. We hope that the price of the full packaged game, including cartridge, manual and box will be no more than 60€ but as the price depends on the demand, you will be asked to answer several scenarii. Cheers Seb

For those of you who want to try but are afraid to install linux, I have set up a VirtualBox machine with the Removers development kit installed on it. Download link is at http://removers.atari.org/softs/download.php under the name JagStation.

Hi, I just made a bugfix release of jlibc & rmvlib. I also added a new example showing how to communicate with the Skunkboard thanks to rmvjcp.

Nice little game!

Hi. As I said, I have found the bug. I don't think I will release an update just for that fix, but here is the patch. In vline.s, replace the block (after label .depth_ok) or.l #XADD0,d0 move.l d0,A2_FLAGS moveq #0,d0 ;; remove move.w SCREEN_W(a0),d0 ;; remove move.l d0,A2_STEP move.l d1,B_CMD wait_blitter d0 by or.l #XADD0,d0 move.l d0,A2_FLAGS moveq #1,d0 ;; fix swap d0 ;; fix move.l d0,A2_STEP move.l d1,B_CMD wait_blitter d0 As every bug, this one was really stupid! Instead of doing Y++ between each inner loop, it was doing X+=W. The bug happened when X wrapped around 65536, so in this case at line 204. Because X was initially equal to 240. Indeed 240+204*320 = 65520 but 240 + 205*320 = 65840 >= 65536 And 65840 mod 65536 = 304. So an artefact occured at X = 304!

Just found the bug, before going to work! Thanks for spotting it. Do you want the fixed version of vline.s ?

Clearly, there is a bug somewhere. I tried to understand what goes wrong yesterday evening, but haven't succeeded yet. Just one question: does the problem also happen when using VirtualJaguar?

Hi again, for the problem with vline, I think the higher value you can give is SCREEN_HEIGHT-1, because the parameter is not the height, but the Y-coordinate of the last point (which should be >= Y-coordinate of the first point). But, I still don't understand why something is put to the right. The intended behaviour is that the Y-coordinate is clipped.

So, sorry, I don't need a Jaguar finally I just had a look at some of my example codes and just realized that I have badly documented these functions. Indeed, the color parameter has to be on 32 bits: the high half and the low half are both used to set the color. In your case, simply change your code to: put_pixel(scr, SCREEN_WIDTH * 0.25 + i, j, RED<<16 | RED); vline(scr, SCREEN_WIDTH * 0.75 + i, 0, LINE_LENGTH, BLUE<<16 | BLUE); put_pixels(scr, GREEN<<16 | GREEN, LINE_PIXELS, pl); Regarding the problem with vline, I need to think a bit about it. Cheers

Hi, I'll have a look at it, as soon as I get some time and a Jaguar near myself. To be honest, these functions are not intended to be really used , but thank you for spotting a bug if any. Cheers

Just one final remark regarding the videos: the first red bar sometimes flicks. This is normal because the code that alters BG in file main.c of example15 (function play_module) conflicts with the DSP code. (i.e. the following can happen: the DSP turns it RED, play_module turns it RED then BLACK, and DSP turns it BLACK) But we still see how it behaves, so no matter! This is very instructive. Thank you again for having done the experiment.

Ah, that's interesting! Thank you for making the experiment. The fact that the lines go in a different direction means that the replay frequency in VirtualJaguar is probably not the one announced, but is probably a bit higher. Also, from what I have seen, DSP emulator does not seem to be cycle accurate: this probably explains why 1.3.2 runs slower than 1.3.1

Thank you for the video. From what I hear, I can say that it is probably the main resampling loop which takes too much time on VirtualJaguar. You can check this point by changing the value of DSP_BG in the file paula.s and recompile it. This will display in RED the number of lines needed to do resampling, which occurs roughly at every half VBL. (the game is to have as much BLACK as possible between the two RED bars, no BLACK => you lose ) What I can say is that the resampling loop of 1.3.2 is slightly bigger (number of instructions) than the one of 1.3.1 (or 1.3.0), but I think it uses better the pipeline and it performs less access to the main bus. Maybe these two points are not well emulated by VirtualJaguar? One thing I have not understood in your tests, did it work well with Project Tempest? BTW, I didn't know PT was working with Wine, thanks for the tip! edit: 1-you will see better the red bars if the VBL is at 60 Hz 2-yes, of course, the replay frequency is the same for Protracker modules!

I didn't try with VirtualJaguar but with Project Tempest, and on my computer, the sound was distorted. I think it requires a lot of power to emulate what is done by the Jaguar, so maybe it is your computer which is too slow (or the emulator which does not use the full power of your computer). Please also note that if you use the cof files I gave, example15 uses a higher replay frequency with version 1.3.2 (about 52 kHz) than with version 1.3.1 (about 46 kHz). This might be the difference!

As promised, version 1.3.2 is now available. Sound engine has been improved.

Hi Seb, How does it perform when the bus is heavily loaded up? What are the latency times like? Hi, I have not yet really tested. But I have just finished to code an improved version which makes less access to the bus. So I will probably release this new version very soon. I am now able to reach the next upper frequency which is about 52 kHz with 8 voices. Apparently, there is still some free time, so an upper frequency is still possible (actually 59 kHz seems to work also!) I would be very pleased if you could benchmark my player with your own code and tell me how it reacts with loads of sprites. To be honnest, I don't really know how to measure what you are asking to me.

Hi everybody, I am very pleased to announce the immediate availability of the Removers library 1.3.1 (as well as jlibc 0.5.7) As usual, it is released under the terms of the LGPL license, so that everybody can use & hack it freely. A source & a binary release are avaliable on http://removers.atari.org/softs/download.php I finally rewrote the sound engine, so that now it is able to replay 8 voices at a replay frequency up to 46 kHz. You can hear the result by testing the binary release of example15 available here: http://removers.atari.org/softs/archives/example15.cof I am very proud of this new engine. I would like to thank LinkoVitch who, with his work on his own sound engine, gave me enough motivation to get my hands again on my Jaguar to begin & finish the rewriting of the sound engine, which is a project I planned to do since more than 2 years. Comments & questions are welcome. Please feel free to ask. Cheers Seb

Hi, I am the author of Atomic. I have no clue at all if it is authentic. Probably guys from the RGC will know better than me. I think you can believe Tursi, if his assumption regarding the origin of this CD is correct. By the way, I hope the auction did not get too high, since it was a free --not for resale-- CD release. And since you can get the cd image free of charge from my website (http://removers.atari.org/) as well as most of my other productions.

Hi, Great. Technically, Another World consists of a custom Virtual Machine and data files. The data files includes the graphics, the sounds, but also the game itself (which is written in a custom scripting language). The VM interprets the scripts. The version you have played uses data files of the remade PC version. The VM has been rewritten from scratch by me. Fortunately, I had some clues on how to do that, since Eric Chahi provided me some source files. It was really fun for a programmer to do this job. Especially, I had fun to experiment several implementations of the VM. I have now three implementations of it: one purely in C, one purely in Assembly (68k), and another one written in Assembly (68k) that does Just-in-Time compilation. (of course, in the three cases, all the graphical & sound job is done with the dedicated hardware of the Jaguar (GPU & DSP)) The version you played uses my favorite engine: the one that does some JIT compilation. I think it is the long version. Well, I can't really say more here. Technically, I would like to improve the sound engine before saying "it's finished". But I fear I won't have time to do that, so maybe it will just stay on my wish-list. Then, I have to discuss with Eric Chahi on how he sees the way we could release the game. I am in favor of doing a cartridge release so that most of the Jag owners could play it. (the cheap cartridge design on which Zerosquare has worked is interesting for that) Hope this answers your questions, Cheers, Seb

Hi, pleased you liked the game. Regarding the "gun bug", could you be more precise? If it happened in the second level (the jail), then it is not a bug, but a feature Indeed, it is the only level where the ammos are limited (so that the only way to pass the guard behind the triple door is that you kill the guard in the room below and then hijack the signal that commands the triple door) Regarding the playability, it should be exactly the same as the original version. I hope Fadest showed you the last version I sent to him where I indeed fixed a small bug in the control system. Cheers, Seb

Great! Hope to be able to be in the 100 lucky guys

Wow, great!

yes please contribute !! (I am the admin of Jagopedia)

Yes, the enhanced version (256 colors) fits in 3.5 MB. So there's good hope for a cartridge release Regarding the number of polygons/frame rate, I can't really say. The only thing I can say is that animation is fast and smooth