Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

SebRmv

Members
 View Profile  See their activity

  • Content Count

    332

  • Joined

  • Last visited

Posts posted by SebRmv

  2. Posted

    By the way, I realize you were implying that there could be a clipping issue due to me going one over the screen size. I know you were just pointing out possibilities without the convenience of being able to run the code at the moment. I want to clear it up a bit. It doesn't matter what ymax I specify. If it is beyond the last visible point in that screenshot it will begin coming down on the right. The length of the line coming out on the right is determined by how much ymax goes beyond that point. I think the highest value before this happens, in this example, is 200.

     

    As for the ymax used in the code I posted, the value used is indeed incorrect. The corrected code, accounting for 0, would be:

     

    vline(scr, SCREEN_WIDTH * 0.75 + i, 0, LINE_LENGTH-1, BLUE<<16 | BLUE);

     

    Thanks.

     

    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?

  3. Posted

    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.

  4. Posted · Edited by SebRmv

    So, sorry, I don't need a Jaguar finally :D

     

    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

    • Like 1

  5. Posted

    Alright, I have another experiment I would like to post about. Seb, let me know if this thread is not the right place for this.

     

    So, I have been playing around with sprites and I have not had any issues there so far. Tonight I wanted to check out the screen methods and throw some pixels around. I made a test program with the intention of drawing some lines with the different methods available: put_pixel(), put_pixels(), and vline(). Setting up and working with a screen is pretty easy. I ran into two issues though. I will share my code and then screenshots that show what I am seeing. These results are the same in the emulator and on the Jaguar.

     

    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

  6. Posted · Edited by SebRmv

    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.

    • Like 1

  7. Posted

    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

    • Like 1

  8. Posted · Edited by SebRmv

    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 :D)

    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!

  9. Posted · Edited by SebRmv

    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!

  11. Posted

    Comments & questions are welcome. Please feel free to ask.

     

    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.

    • Like 2

  12. Posted

    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

    • Like 10

  13. Posted

    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.

    • Like 5

  14. Posted · Edited by SebRmv

    Hi,

     

    Alright then I guess it is no bug since I passed that particular scene the way you described it but thought that I had chickened out and made it to that hatch the alien opens only by luck. Fadest wasn't sure about the gun part so I assumed it was a bug since the shooting animation is there but it won't shoot...

     

    Great.

     

    I have two more questions if you don't mind. Was the version we have seen on Jagfest a straight port of the remade PC version or did you combine elements of the old game with stuff from the remade one? It was obvious that the backgrounds looked much better than on my St version from back in the day, but then I wasn't so sure about some of the cutscenes and the charakters.

    Please consider that I only judge from old memories so I can be very much mistaken about what I have in mind about the looks.

     

    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.

     

    Was this version of the underground cave with the watertank shorter? I remember some tentacles hanging from the ceiling etc...haven't seen them there but then I always died while running away from the water so I might not have advanced far enough.

     

    I think it is the long version.

     

    Any way with all this said I had great fun playing this version on the Jag and I think it is cool we will have not only Flashback but also Another World.

    I spent quite some time with this game and enjoyed it very much even though I seem to suck at it and died quiet a lot;-) Fadest had to help me out on the rolling part, didn't remember that at all ;-)

    Well then, when do you think we are going to be able to play it on our own machines? :-)

     

    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

  15. Posted

    Now onto Another World which I played for quite some time and it was a pleasure to see it running on the Jag, the game had still some bugs (gun wouldn't shoot or I did something wrong) but it looked great with the updated backgrounds from the PC version. Here and there it still felt a bit rough around the edges in some instances concerning the gameplay (jumping over pits while running and then falling down, being a bit frustrating) but I did not have the original for comparasion so it might be very well be exactly like that in the original game.

     

    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 :D

    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

  20. Posted

    As for the pause mode.

     

    1) Shoot the invader, this will put food in the snake pit.

    2) Grow the snake to a length of 25 and a bonus will appear in the cycles maze.

    3) grab the bonus there and it'll randomly grant you something in the main game (life, gun, shield, sideshot, smartbomb, laser)

    4) do nothing (ie, PAUSE) and it'll eat away at your shield :)

     

    Hope that helps!

     

    You crazy guys :D

    • Like 1

  22. Posted

    Yeah, you can detect console mode. The simplest way is to send three NOPs. The first two will fill up the command buffer, the third one will time out (the timeout may hiccup your code, so don't do this during the game loop). After the third command returns, check the skunkConsoleUp variable - if it's 0 then the PC didn't respond.

     

    It's not really critical, though, you won't crash if it's not up. Your commands will just timeout. After the first timeout Skunklib doesn't try to reach the PC anymore. (Of course, that could be a problem for /reading/, but it's not for writing.)

     

    You may want to use a more reliable mechanism than the one in there by default, but it's probably good enough for a high score table. SebRmv did a much more advanced filesystem implementation for his lib.

     

    Just to clarify, yes I have made a more advanced FS implementation (I have still to release the client :))

    However, I do not really handle communication errors properly as I assume all is good in a brave new world.

  23. Posted

    Yes I imagine perfectly the nightmare it should be to write this correct by hand.

     

    Actually, I thought it was possible to write madmac macros and conditionnals to circumvent the bug but unfortunately, since it is a one-pass assembler, it cannot work completely.

    Fortunately, now there is SMAC!

     

    Thanks again for this thread.

  24. Posted · Edited by SebRmv

    Yep, tricky little beast that Jag is.

     

    Nonetheless: Congratulations to Seb for sticking with me and figuring it out on his own.

    Rdemming got it on JSII as well. Nice job guys!

     

    Well, we got some help.

    But still, I am happy to have guessed the rules correctly.

     

    Thanks for having been an oracle.

  25. Posted · Edited by SebRmv

    Finally, just had a look at smac source code. It seems that the five rules are:

     

    1 - JUMP placement must ALWAYS be long aligned.

    2 - JR placement is FREE

    3 - All external page jumps must be LONG ALIGNED!!!

    4 - All internal page jumps must be word offset from long aligned!

    5 - Two NOP's must ALWAYS come after a JUMP or a JR instruction.

     

    It seems also that it is forbidden to make a JR from main memory to local memory and vice versa. But what about JUMP?

     

    Is that correct Gorf?

     

    --

     

    First I have to say that I am impressed that you found this on your own.

    Especially rule 4 seems to come from nowhere. But I guess it is somehow related to rule 5.

    How did you figure out? By looking at the NET files?

     

    --

    Let's continue the technical discussion.

     

    What happens when interruptions are enabled? How does it behave?

     

    What happens if each rule is individually broken?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...