Jump to content

danwinslow

Members
  • Content Count

    2,767
  • Joined

  • Last visited

Posts posted by danwinslow


  1. Sid, I find your attitude on this point to be annoying. Whatever small spark of interest I had for the FB2, you have managed to kill it with your hysterical ranting about how cool it is and how we should buy it and if we don't we hate atari. Personally I wouldn't buy this thing under any circumstances. Why?

     

    Just because of this annoying ass thread. How's that for an excuse?


  2. I'm not following you. The original 2600 was a big hunk of machinery. It can't be 'a 2600 on a chip' because a 2600 is not a chip. I guess you mean that its some kind of exact emulation, but again you miss the point - It's not *actually* the same. Yes it plays the same (maybe) but thats not the point.

     

    And anyways Grames has had like ZERO to do with the 2600, or *any* of the old atari lines we love. All they are doing is capitalizing on the genius of the Atari engineers of old by churning out some copies.


  3. OK....this may be in the wrong forum, but technically I think this is a 16 bit computer from Atari :)

    Here I sit looking at a nice little Atari Portfolio....and I can't turn it on. I have no manuals, and googling did not produce any definite info. Actually it produces a *lot* of info, but nothing a simple as how to go about turning it on. Any clues? And yes, its plugged in.


  4. Ah, gotcha, very cool. So I assume you could theoretically send more..say 10 bytes per vblank? It looked like you were doing stage 1 vblank...so thats pretty time critical if I recall correctly. But anyways there's no real reason that this needs to be slaved to vblank for my purposes, so some other interrupt would probably do as well.


  5. You know, I am no 6502 assembly jeenyus...but if I understand whats going on here, this is a way to pump bits out of one of the joystick ports driven by vblank? Call me Capt. Obvious, but I just wanted to make sure. I could use this code for something I want to do, if you don't mind me borrowing it.


  6. Gotcha, thats what I thought.

     

    Well, if I get the game up and on the net on my TT I'll post the link. It's in kind of an unusual language that I will need to get ported over. I'll need to get GNU C++ moved over, and then use that to build the compiler from sources...in other words, don't hold your breath :)

     

    ANyways, its great to see a BBS back in action and I'll be sure and stop by.


  7. Dark, do you mean that the ST thinks its talking to a modem but really its an ethernet NIC?

     

    Speaking of modem games, I have a 16 player text MUD I wrote some years back that I would like to get hosted. It wants sockets on the inside but I probably could change that over to virtual serial connections or something. If you are interested, Dark, let me know.


  8. Well, the display slots idea would handle both of the boundary cases you mention, but it could possibly generate a lot of DLI's I guess...if all sprites were on the same y, then the 'first' four would get displayed, then the next four, so for 16 sprites, each one would get displayed every 4th scan...which would be pretty blinky I would imagine. If all sprites did not overlap ( which might be impossible, depending on how tall your sprites are ) then there would always be a free slot in the display slots array.

    My feeling is that without special screen arrangements and limitations on movement it will just be too unwieldy and slow. Allowing for full and free motion of 16 sprites is just not going to be easy

    Maybe you could prevent overlap in certain cases...ie., when you know that the proposed motion for a given sprite would move it into overlap, you could block that motion.


  9. Well...it would work a *lot* better if you had the sprites all being the same vertical size...and if you had the screen divided up into 'zones' that were as tall vertically as the sprites...and the sprites could only fit into zones, ie., no single scanline vertical motion. That way it would be very clear when something is overlapping something else. Otherwise you are going to have to do lots of compares. But thats pretty restricting, so how about :

     

    One thing maybe is to not only have your regular ring buffer, but also have a special 4 slot array for holding the 'active' sprites info. As your scan line moves into the display zone for a sprite, you copy that sprites id number into the 'active' buffer in slot 1..keeping track of the start and end y scanlines...then as you move down the screen, keep inserting sprites as you run into them...until your 4 slots are full. If you run into any more while your slots are full, they don't get displayed. Also watch the ending scan lines, and as the scan line moves beyond the bottom of any sprite thats in the active buffer, you remove him and thus next time you run into a new sprite you want to start displaying you will have an empty slot. You'd also need to bump some kind of counter for each sprite, in order to remember which ones got displayed last pass...if you only paid attention to the sprites that are valid for the scan line and have the *lowest* usage count, that should swap in some of the ones that got left out last pass.


  10. I am not really sure what you are trying to do....what do you mean by 'zone'? Are you trying to get more than four sprites on a scanline, or just more than 4 sprites to a screen, or both?

     

    If I understand, for the case where you have more than 4 sprites on a scanline, you could just cycle through them 4 at a time, which is what that 'ring buffer' idea from the article is about. You have them sorted into an array, and you bump the start point by four each time, wrapping back around at the end.

     

    But it still seems like you could have cases where a single sprite would overlap more than 1 'zone'....not sure what you could do there.

×
×
  • Create New...