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

Asmusr

Members
 View Profile  See their activity

  • Content Count

    4,006

  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Asmusr

  2. Posted

    56 minutes ago, GDMike said:

    I'm looking for what isn't listed that I'm not aware of though. I didn't want to push it to vdp RAM, I was hoping to just have my data in high Mem where it is already and mov it from there.

    You have to move your data to VDP RAM before you can save it. And you can only load data from disk into VDP RAM. 

    • Sad 1

  5. Posted · Edited by Asmusr

    Thanks for the comments and suggestions. Just to explain, for a fast raycaster I think I'm well covered by the one I already made. If I decide to make another, texture mapped one, I'm well aware that it wouldn't run fast enough for an action game, but for a turn based RPG game it could be fine. See this video where I have set the speed to 2 FPS. It's moving 1 block at a time and turning 90 degress. I think that would be doable on the TI. I'm a big fan of RPGs like Might and Magic III.

     

    [video deleted by mistake]

     

    • Like 1

  6. Posted

    1 hour ago, speccery said:

    Thanks for sharing your thoughts, interesting discussion here. When you say that the bandwidth is around 2k per frame on the TI, what is the frame rate you're assuming? Probably not 60fps, more like 30fps?

    That's for 60fps. But 2k is if almost all your instructions are movb to the vdp, which is difficult to achieve in practice.

    • Like 1

  7. Posted

    2 hours ago, TheMole said:

    Not sure if this is correct though. Even looking at the thumbnail of the video, your horizontal resolution seems higher than what the 9918a can display using the 4x1 macropixel method. Look at the slope of the leftmost block. That looks like it uses a 1x1 pixel resolution to me. I think you've only applied the 4x1 limitation to the textures themselves.

    This version has a superimposed 8x8 grid. Where do you see that slope?

     

    grid8x8.thumb.png.9e7f96e187e938a23c5653bb4e030139.png

    • Like 2

  8. Posted

    7 hours ago, PeteE said:

    I was working on a websockets interface for TIPI as a goal for emulation.  Let me clean up the code a bit and I'll share it.

    That would be helpful since I have not programmed in Python before. My concern is that if it differs too much from the master branch it would no longer be emulating the TIPI. 

     

    Doesn't the current programming model mean that the RPi is running with high CPU load 24/7? I wouldn't want my emulator to do that.

     

    • Like 1

  10. Posted

    Yesterday I looked into implementing TIPI support in JS99er. My idea was to use websockets as the interface between JS99er/TI and the python code, which would be slow, but I don't think that would matter for the emulation. I got stuck because the python code is implemented as a polling loop instead of being event driven. What would it take to reverse control so that TipiMessage is notified when a byte has been received instead of polling for it? For the normal code branch I guess it would mean moving the polling loop into libtipi. 

  11. Posted

    This video is made on a PC, but it's showing graphics that the TI-99/4A would be capable of if it was fast enough. It's using the 4x1 fat pixel bitmap mode of the 9918A that you get by setting the pattern table to a fixed 11110000 pattern and only updating the color table. I'm pretty sure it wouldn't be fast enough on a TI for a first person shooter, but for a dungeon crawler game it might be fine. 

     

     

    • Like 8

  12. Posted

    9 hours ago, speccery said:

    Thanks to the tip from @Asmusr I used classic99 to measure the speed of my code. With some simple changes I was able to get the time of a one bit left shift for 16 scanlines down from around 135K cycles to about 97K cycles. Only modifying the pattern tables, not touching color tables. There are in total 32*16=512 VDP RAM reads and and the same amount of writes. Come to think go it, my code actually probably reads one extra strip at the end. Anyway, in the big picture that's around 100 cycles per each VDP access and processing.

    If you want to speed things up you should look into how to avoid any VDP reads and how to avoid settings up the VDP write address more than once. 

    • Like 1

  13. Posted

    1 hour ago, speccery said:

     

    Overall it was fun to do some assembly programming after a while. One question which came to mind was that how would one easily do cycle counting, does classic99 for example support it? I.e. reset cycle counter at a break point, and read the count at another breakpoint?

    Just add a "breakpoint" like T(start-end), e.g. T(A000-A030) to count the cycles between >a000 and >a030.

    • Like 3

  17. Posted

    I'm experimenting with various things. One is the floor pattern, as you will see.

     

    You can also shoot the baddies now, but the baddies can't shoot you. 

     

    Spoiler

    And for fun you can also shoot the walls. That means you can break out of the map. I'm displaying your current memory address at the top right corner. You can walk out of lower RAM and into DSR space at >4000. When you reach the cartridge area at >6000 you may experience "black ice" in the shape of immutable memory. Maybe you can find you way into the busy >8300 region, and travel on to the >A000 region and kill the evil program?

     

     

    raycaster.rpk raycaster8.bin raycaster.dsk

    • Like 5

  22. Posted

    1 hour ago, LASooner said:

    If you're working on sprites, If we could define a range as a flip book to work on sprite animation that would be useful

     

    ie, select sprite 3 as the first frame and sprite 8 as the last frame and have it cycle through all sprites "frames" at a defined frame rate.

    It's not high on my to-do list because you can click manually through the sprites. Actually my to-do list is empty at the moment. 🙂

  23. Posted

    54 minutes ago, PeteE said:

    Please don't truncate the number of characters.  The .mag files are in an easily-to-parse text format, which makes it possible to extract the data directly using awk or a custom tool as part of my build script.  I rarely use the export features in Magellan.  I don't think you should worry about files saved with super character set to be loadable in older versions of Magellan.

    I thought so. I have uploaded the new beta version with more sprites and even more characters to https://magellan.js99er.net/

    This version also includes an 'Open recent' feature.

    • Like 2

  24. Posted

    If you're running Magellan in Windows 10 and it looks blurry, you can disable the scaling by opening the properties for the Magellan.exe file, click Compatibility, click Change high DPI settings, check Override high DPI scaling behavior, and choose Application from the list.

  25. Posted

    I have a question about how mag files should work with the super character set. Internally Magellan will always use the super character set, so you can change character set size freely without losing and data. But when a mag file is saved, should the number of characters be truncated to the current character set size? The former has the advantage that mag files are compatible with older versions of Magellan if you don't use the new feature. The latter has the advantage that you never lose data even if you changed to a smaller character set. The beta version is doing the former, but I'm leaning towards the latter. What do people think? 

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...