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

whoami999ster

New Members
 View Profile  See their activity

  • Content Count

    52

  • Joined

  • Last visited

Posts posted by whoami999ster

  1. Posted

    On 3/5/2021 at 6:03 PM, Asmusr said:

    Yes. The F18A can mirror sprites both vertically and horizontally by setting bits in the 4th attribute byte. If I run out of patterns again, I'm going to use that approach for something like this explosion where you would hardly notice if the left and the right sides were mirrored. 

    image.png.00b4d99cf8eb937479f46231af6f06f0.png

    genial!

  2. Posted

    On 5/7/2021 at 8:44 PM, Asmusr said:

    A bit of technical info:

    • As mentioned before, the scrolling background requires far more than 256 characters in total, and it's very close to 256 at the individual screen level. If I need to save some patterns for displaying score, fuel etc., I need to find the best alterative for some patterns. That's what I have been working on for the last couple of days.
    • The original hardware had sprites with a size of 32x32 pixels. The TI sprites are only 16x16, so I'm working with virtual sprites that consists of 1 to 4 hardware sprites. One example of a virtual sprite is the orange fuel tank, which consists of 4 hardware sprites.
    • I have worked on offloading a substantial part of the work to the F18A GPU, so currently the CPU is only aware of the virtual sprites while the GPU is handing everything to do with the hardware sprites.
    • The GPU is sorting the sprites according to their 3D distance from the user and is applying priorities (which sprites overlap each other) accordingly.
    • The GPU is also calculating collisions between sprites and reporting this back to the CPU. That alone would take almost half of a CPU 60Hz cycle.
    • The last thing the GPU does is to generate sprite attribute tables from the virtual sprites. Since there are up to 16 virtual sprites, and each consists of up to 4 hardware sprites, 64 hardware sprites may be required. That's partially resolved by having one sprite attribute list at the top of the screen and another at the bottom. Sprites that overlap are added to both lists. And a scan line handler is changing the VDP register that's managing the sprite attribute table on the fly (that is also possible on the 9918A, but because of the 4 sprite per line limitation it has limited value).
    • All this is done during blanking, between the last line of the screen and the first line of the screen are drawn. 
    • The CPU is still doing everything that has to with controlling the user input, moving the virtual sprites, and then it's doing the much simpler task of checking the sprite collisions reported by the GPU.
    • There should still be time left on the CPU side for an advanced sound player and other game logic.

    What I can surely understand is that this wondefull example of arcade on TI99/4A with basic configuration even with 32K expansion will never be sufficient to manage the game graphics requisite . that's really a pity ... maybe a very semplified versione would be possible? what's you opinion ? 

    Just  a clarification for a very newbie : "a scan line handler is changing the VDP register that's managing the sprite attribute table on the fly" it means changes of the SAT itself (i.e sprite position, color,..) or chage the position of SAT in VRAM ?   

      Thanks a lot for your work with TI99/4A always at the top level

     

  6. Posted

    On 12/31/2020 at 6:30 AM, Retrospect said:

    Here's a nice little blaster for you.  Robots Of Death.  You're in the death arena, in a faraway galaxy that nobody has ever heard of.  Even I haven't heard of it.  I don't even know what it's called. Anyhow, here you are, in your blaster ship, and you've got to kill all these robots.  The robots will head towards you autonomously, if they touch you they will kill you.  They aren't your only problem, you also have to deal with the "XY Zappers" that move along the perimeters, randomly zapping into the arena. Then there's the "Screaming Skulls" which move up and down, and left and right, just to get in your way.  Those will kill you too.  Just when you thought it couldn't get any deadlier, it's worth mentioning the walls of the arena are electrified and will fry you on contact!

     

    In the first few levels the robots are fairly steady, but they do get faster from level 3 onwards.  The XY Zappers are just lethal throughout but their firing rate does pick up after each level ... you've really got to stay on the move and just hope and pray they don't zap you.  To complete a level you've to do either of two things, shoot all the robots dead, or manage to stay in the level for the time it takes for the bottom XY Zapper to pass the arena 32 times.  I don't think that's even possible without dying.

    Take note; you do move quite fast but you can't shoot AND move .... you can rotate up,down,left and right whilst shooting though, this comes in handy if you wanna show off in front of your mates or you're surrounded by robots from all sides.

    When you complete a level and move onto the next, the robots will change shape and colour.  They do this until level 16, after level 16, old shapes start to come back at random, but the firing rate of the XY Zappers and the movement speed of the robots will be locked at the speed of level 16, even if for some insane reason you reach level 32.  

    If you get a high score (you'll have to beat mine but it's not hard once you get into the game) you'll be presented with a screen congratulating you, and given the opportunity to write your initials .... you're allowed three letters, just press the three letters and it will be accepted as your initials you don't have to press enter.

    I want to hear from people about this game, how far you've managed to get and if you think it's too easy or too hard?  I personally think it's as hard as a drunken Scotsman.  But it was never meant to be a push-over!

    ROBOTS-E, ROBOTS-F, ROBOTS-G < Editor Assembler 5 version
    ROBOTS-X < Extended Basic version

    thanks for sharing ... good job ! 

    now let's wait for some top player high score ...  

    • Thanks 1

  7. Posted

    On 12/17/2020 at 4:38 AM, PeteE said:

    I was inspired by the C64 demo in this post and decided to port it to the 99/4a.  The lack of colors was indeed a struggle, but I think it turned out pretty okay given the limitations.  There are three major effects that are combined to produce the various animations.  The first is color cycling, which changes the contents of the color table to create motion.  The second is 8 rotating color bars on screen at 64 different angles, done by changing the pattern table address.  The final effect is the interleaved screen+color tables - using raster horizontal sync, which changes the screen image table address and color table address on every line.  This is using VDP graphics 1 color mode!

     

    I've only tested it working in Classic99 and on a NTSC 99/4a console.  It wasn't working in JS99er or MAME, maybe because it relies on the VDP status collision flag being set by transparent (color 0) sprites?

    copper8.bin 128 kB · 51 downloads

    Hi Pete

     

    no way to share the code of the demoscene?

    For me this demo is rocket-science stuff I would be very interested on how it works ... where/what is the starting point to create such demo ...   

    The best for me is a sort of tutoria thread that explain step by step how to create this demo ... but I know I'm asking the impossible ... anyway that would be very helpfull to have a look to the coding ... 

     

    Thanks once again for your commintent with this wonderfull AMachineMakeEverything system

    All my best for a great year end... for 2021 better to say nothing

    Francesco

      

  8. Posted

    that's exactly this 512K that make me confused (with all the rest LOL) .... to much wizardry here :( ... KiB stand for Kbits ? 

    I know that my explanation is at kid-garden level ... but help me and I will grow up quickly ... I'm reading tons of document/books and i need time to metabolize but with practical example everything is boosted... 

     

    @Asmusr : no way to have an example of one frame from the demo? 

     

    Thanks for your patience and your time

    Sincerely 

    Francesco 

  9. Posted

    ... but in which memory area did you stored all the 180 frames.

    just to simplify ... then you load the first two frames in the buffers and then load/dispaly the name table with the content of the first buffer and then load the second one in the and in the mean time you get a new frame from the "frames staging area" and so on all this into an infinite loop ?

    something like that? or I'm very far from... 

  10. Posted

    On 2/17/2017 at 5:46 PM, Asmusr said:
    Sometimes' Piet Mondrian pictures gave me an idea for an animation that would work in the TI's odd color modes. The animation is a simple roto-zoomer programmed in Java, resulting in 360 256x192 images.

     

     

     

     

    post-35226-0-11678700-1487349025_thumb.png

     

     

     

     

     

    I originally planned to run the animation through a project I have been working on for a while: a 'video encoder' that takes a series of images and calculates how to get from one image to the next with the fewest possible changes. The encoder is also programmed in Java, but the result can be played back on the TI given enough storage space. Unfortunately I could not get the desired result from the encoder because it's based on "half-bitmap" mode, which is more flexible than graphics I mode, but makes double buffering difficult. If you want to see how far I got with this, open "rotozoom-encoder-8.bin". This example uses around 1100 bytes for each of the 360 frames, which fits nicely into a 512K cart. As you can see it has a lot of noise, resulting from the lack of double buffering.

     

     

     

     

     

    I then switched to Graphics I mode, and instead of using the encoder I imported each image using the map import code from Magellan (which was improved in the process :-). This method resulted in more bytes per frame, so I could only fit half of the frames (180 frames) into a 512K cart, but on the positive side Graphics I mode can easily be double buffered. The result is quite pleasing to look at as you can see from "rotozoom8.bin" and "rotozoom8.rpk".

     

     

     

     

     

    Note that these carts do not require 32K as the code is running primarily from scratchpad.

     

     

     

     

     

    rotozoom-encoder-8.bin 512 kB · 22 downloads

     

    rotozoom8.bin 512 kB · 24 downloads

    rotozoom.rpk 106.1 kB · 9 downloads

    What is meant for double buffering ? 

     

  11. Posted

    thanks and once again I completely missed the explanation in teh Roto-zoom animation threads... thanks also for the hint but now it's a challenge for me ;) I will do the "graphics" by myself ... thanks once again also for yor patience... 

     

     

  12. Posted

    Thanks a lot Rasmus above all for your patience... 

    just to get an idea ... how many "pictures" (frames) did you produced to get this animation and on average what as the "dimension" in bytes... 

    If I well understood you did it with Magellan ... 

    No way to have also the Magellan File? ... 

    Thanks as usual :)

     

  13. Posted

    but normally the "graphics" should be in the source code right?

    I exactly placed the breakboint at >6020 and the step by step I found that code was little different from the source ... maybe I was wrong...

    Let me try to compile with xas99 ... but even without the "graphics" do you think that assembly step will work ?

     

    Thanks and have a nice weekend

     

    sorry for boring you ..would you like to describe high level your source code (like the documentation for the smoothscrolling that was very brillant)  

  14. Posted · Edited by whoami999ster

    Thanks as usual Rasmus ... that's what I mean for sharing the knowledge! 

    Do you mind if I will come back to you with some questions?

     

    Have a nice day/night whatever you're placed 

     

    ....

    in the mean time I tried to compile decoder.a99 with winasm99 but no no success ... undefined symbol for FRM2 and undefined opcode XORG

    I had also debuged rotozoom8.bin but the disassembly is quite different from decoder.a99 

    Maybe I'm missing something but I was not able to find in the source code the "graphic" part deinition ... where I'm doing wrong... 

    maybe should be better to move the discussion to the Roto-zoom animation thread ? or email :)

     

    thanks  

  15. Posted

    Thanks a lot Rasmus , thanks for your usual support and patience ... from your hints I guess I've understood the main principle of roto-zoom demo ... If you don't mind and you still have the code , I kindly ask you if you can share the code of roto-zoom demo with your illuminant explation or remarks  ... I'm very interested on the basis of the demo ...

     

    The TI hat-demo works on the same concept of roto-zoom ? 

     

    Thanks once again for your help 

    All my best

    Francesco 

  16. Posted

    Thanks Gentelman I knew that I was not alone ... The only point is that my background is very poor so please I kindly ask you for some "high-level" hints and simplify the explanation id possible... 

    I'm interested from the concept to possible techniques that allows to develop a demo like the Rasmus one (that's very very close to the C64) ... 

    I know he's a generous guy that would kindly share the code of his demo ... that would be very helpfull for me to study...

    I'm not interested to realize exactly the C64 demo but to learn how to...   the demo from Rasmus would be the perfect start for me 

    Even some documentation/books or links that could help me to learn this techniques are welcome... and of course your suggestions but for a dummy level like mine...

     

    Why don't start a new thread as tutorial (like Matthew thread for Assembly) : demo for dummy or demo from scratch ... 

     

    Thanks once again for your time e patience

    Ciao

    Francesco   

    • Thanks 1

  17. Posted

    I'm pretty sure that is possible for some TI99 guru (maybe with less color) ... but someone could help me to understand how this demo could be realized?

    In my heart I can undestand that is not rocket science but how/where to start ? any hints from the TI99ers guru ? even something of high level...

     

    thanks a lot in advance for your patience  and thanks for sharing your knoledge

     

     

  19. Posted

    5 hours ago, jstimson said:

    I assume everyone has looked over at the Colecovision version of Time Pilot.  Given it uses the same video chip as the TI, it shows what could be done.

     

     

     

    I love you guy but nothing comparable with the version of Retroclouds ... did you notice the difference ?!? .... one is colecoxyz and one is TI99 arcade like... 

  20. Posted

    On 2/7/2020 at 9:27 PM, jwild said:

    It may seem like I don't have anything else going on in my life....but today is Friday and I had to jump right on testing this new release.

     

    I gave this release about 5 plays.

     

    It appears the ending of a level with the "split tix" message even when there is only one tix has been fixed.

     

    I did discover a new issue where i can trap a single tix inside a box, but the level does not end.   i can go around the map and make other boxes and the level will end once i've captured enough area.   in the meantime, the tix bounces around inside the box i drew around it. 

    wow you're a quix killer! 

  24. Posted

    You're so kind ... thanks a lot again ... 

    I just compiled the source pgm in the .zip directory tms9900 and it works perfectly like tpilot1.obj in the same directory...

    Now it's up me to understand the code (line by line :( ) that will be an adventure... 

    Thanks you so much again for this very good example of game template ...

    I never thought that the TI99 would be able to make similar games in a similar graphics mode ... I am from the 80s and my memory of the TI99 after hours and hours of typing programs I found myself with games with jerky movements and fluidity of a snail ... now 30 years later I want to work hard to understand what it meant to make a real video game on the TI99 ... it takes patience but I will succeed ....
    Thanks from an old TI99 enthusiast ..

    Any other suggestion, recommendation, book, listing , example or diagram that comes to your mind is absolutely welcome

    Get in touch

    Francesco

    TPILOT4.obj TPILOT4_ListingFile.lst

    • Like 3
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...