Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

14 Good

About kezax

  • Rank
    Space Invader
  1. Hello everyone, I wanted to make a screen with two quad sprites on the left and two quad sprites on the right of the screen. And while doing that, I remembered the RESP registers can be triggered only once per line, unless their associated NUSIZ instruct the TIA to output several copies of the sprite per line. Which cannot occur when using quad sprites since they are only 1 copy. Some time ago, some people in this forum played with the RSYNC register, to introduce a delay in the display and make all graphics appear shifted horizontally on the screen, by a few pixels. So I thought that maybe there would be a way to trigger two HSYNC per line using RSYNC, and that would also permit the TIA to reset its state regarding sprite display, and so to display two quad sprites per line. Do you think that could be a working solution ?
  2. Yep, the texture is tile based and the tiles are rotated before being output to the extra buffer
  3. The texture is rendered into an additional 8k screen buffer, then Suzy draws and scales lines from it, line by line, to the screen buffer. There are tricks to draw only the needed parts of that texture (in shape of cone). Most of rendering loop was finally implemented in pure asm. At some point, I began to make plans to use this technique to also move over the checkerboard and render a Mario Karts clone with a full circuit, but then we decided the best linking theme of the demo would be Devil's Show, and this sequence had no more reason to be part of the demo.
  4. Hey, thanks ! It's not because I made one that you can't do it anymore We never see enough of them on the Lynx maybe you'll find a better way to do it - actually I have no doubt ! Some other parts of the demo required a lot more work to come true. Final size of cartridge before padding, is about 132kb, but if we would have had more time and would have encoded smallfont only one time, we would fit under 128.
  5. And here you can watch the final version of our demo:
  6. Hi @enthusi, I wanted to congratulate you and your team for your demo, it was really great to watch, and honestly the results of the compo were totally uncertain to us, until the prize giving. A few weeks ago I found a port of the Oxygene demo on the Lynx, and I could not believe during the show, the framerate that you achieved in your 3D world (almost as fast as that "polygon stream display" algorithm). Would it be possible to make an interactive version of your engine, where the user would be able to go where he wants ? I was blasted by the length of the run in that world, and I still can't figure out what was actually precalculated and what was not, it would be great if you could you give some insights ! Anyway, cheers for making a demo on the Lynx, she deserves more love !
  7. Hi, I am the main coder behind the Devil's Show. The sequence of the hummer was inspired by ideas of Remdy, another coder, and Exocet, our graphist friend. It is inspired by the video clip of Aphex Twin Windowlicker, and by the Silly Venture itself, which proposes every year to go on Friday evening to a Gdansk club in a hummer limousine playing Atari music, to enjoy a nice concert there and a nice polish dancer making a nice show called the Devil's show
  8. Hi @rj1307, I would like to get one too if it is possible ! Thanks !
  9. I would like a SD cart too, please
  10. To add rendering of a sprite to the rendering of the raycast is possible but not easy - not much time left. But it is possible, it was done in the final demo (including handling of a mask - to simulate going in front or behind a wall...). Sprite takes 8 bytes more RAM to be handled properly. Agree with AkashicRecord, it is heavy on RAM - and most interestingly, not fixed RAM size - depends on what is displayed. So, all the game logic variables which are actually const should definitely not be coded in RAM. And correct number of bits should be used, too. In the demo version, 24 bytes of RAM are reserved for multiplication table pointers, to avoid having to set any of them to the same value, more than once. It was a try to write fastest possible raycast implementation. However, holding some of these pointers represent very little gain of time (a few scanlines) and finally more waste of RAM than anything else, so I guess their space could be reused for something else. Also, there is not enough time to compute that at 50Hz, maintaining the display. One new frame is computed on an average of 3 or 4 frames per second.
  11. Hello guys, I would like to share with you something new I have managed to code for the VCS, it is based on Joe Musashi's idea about how to display a raycasted 2D map (http://atariage.com/forums/topic/229083-ray-casting-engine-demo/) Last week-end, there was the SV2018, a Atari only demo party in Poland, and with some friends we released there a PAL demo featuring that effect: https://www.pouet.net/prod.php?which=78742 And as I have been using this AtariAge website since the very beginning (1 year and 2 months ago), and found a lot of help and resources to understand how to code on this amazing hardware, I told myself it is time to give back to the community. So first, there is a GitHub link about the raycasting, with explanations, interactive 2600 demo (you can move with joypad), and C++/SDL program which was used to validate the algorithm before implementing in ASM, then to generate data tables for the ASM too. Here it is: https://github.com/Javanaise/vcs-demo-raycaster Also, I would like to thank in no particular order, SeaStGruff, Joe Musashi, Tjoppen, SvOlli, Darell Spice Jr, Thomas Jentzsch, eshu, Omegamatrix, Glenn Saunders, Andrew Towers, Martin Arndt, for all their teachings, findings, sharings, and for also being great sources of inspiration Thanks everyone, you are awesome. The interactive demo for the raycast is adaptable for the NTSC system, but might require as it was finally done in the demo, that the "converter" routine (from raycast data to ready to display data), uses fastest speed algorithm, as described in the explanations, and forced to run only between VSYNC and frame drawing (this is where there is more time). In that version even in PAL, the screen sometimes jumps a little bit, because conversion occurs between end of frame draw and next VSYNC, and sometimes it's missing a little bit of time to complete before end of timer Enjoy, Kezax RaycastDemo.bin
  • Create New...