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

sack-c0s

Members
 View Profile  See their activity

  • Content Count

    1,213

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by sack-c0s

  3. Posted · Edited by sack-c0s

    To be perfectly honest I am not very interested in retro-gaming,....and unless I can put a BSD or Linux on it and use it as some type of appliance I am not too keen in having it around. Is there any real value in me maintaining and collecting this stuff?

     

    That's pretty much the opposite of me really - doing those things abstracts any personality out of the machine and turns them into a generic commandline-driven box. The thing I do love about 8/16-bit machines is that love them or hate them, for better or worse, for all their quirks and annoyances they are all different and have their own personalities

    I'd keep the machine and have a play with it and explore it a bit. It'll have its own set of games that play to the strengths of the platform, it's own quirks and strengths you can exploit to do cool stuff and you'll probably enjoy it.

     

    Get rid of it afterwards if you don't think t's for you - but I'd at least give it a chance.

  4. Posted

    I think it might be important to distinguish between something that is an "upgrade" to the system and something that makes it an entirely different system altogether. The question was asked, "Is it still an Atari 8-Bit?" If it will still run all of the software written for the unmodified system, then it IS still an Atari 8-Bit; just one with an "upgrade" that gives it new abilities. Fair. But if the system does NOT run all (reasonably) of the original software, then no, it is not an Atari 8-Bit. It is a new system based on the Atari 8-Bit. Maybe? Anyone?

     

    I think this is the problem - for the purists it's 'not a real Atari', but for those who just want to go all-out and upgrade anything they possibly can then it's not that much of an upgrade. It's kind of an uncomfortable middle ground.

    • Like 1

  6. Posted

    could you get a bit more precise with your question?

     

    It's just in the original some of the notes are more subtle and it glides between them without restarting the instrument. Not having that in this version creates a bit of a jarring effect and I was wondering if it was possible to fix that with this insturment set, because apart from that one thing it sounds pretty good.

     

    That said throwing a bag of cats off the top of a skyscraper would sound better than the Atari/amiga version of the music so you didn't have to go so far to beat that :)

  8. Posted

    Another consideration albeit not major - the screen shakes before the bubbles drop a level. I wanted to retain that. Doing a fine shudder with GTIA modes active means the step has to be twice as big.

     

    Fade the border up and down? It'd be noticeable in you peripheral vision and a lot easier to implement. You can even change the rate to convey more or less urgency

  12. Posted

    the C64 does a decent job of the game. Yes the Atari has no sprites but to be honest the 64 version tends to outstrip the available sprites and end up using character graphics anyway and the Atari has a bit more CPU grunt behind it which should avoid any stuttering or slowdown.

     

    I'd just forget the 'getting the highest quality graphics' argument for the moment - people who want that can just play the arcade version. It's a game (not a demo) and the objective is for it to be smooth and fun. I reckon that can be pulled off.

  13. Posted

    my thought is 'stuff obsessing over the rainbows and you can get a solid, playable version of rainbow islands out of the Atari no problem'.

     

    I get the feeling the rainbows would end up looking like the gameboy colour versions and some people would crack the odd joke that the people who shout the loudest about having the most colours available can't do a rainbow, but in response you could just fire up the smoothest 8-bit port out of the lot and just ignore them :)

    • Like 3

  14. Posted · Edited by sack-c0s

    True random would be a debugging nightmare and lead to generated scenarios that weren't possible or fun.

     

    What is a better way of doing it is to have prefabricated level components and have those tagged up with metadata which contains additional information about how this fits into the grand scheme of things, such as how it contributes to the difficulty of the level, other elements that you might want to control (e.g 'is this a more action-oriented sequence? is this more puzzle-based?) that would allow the user to control the kind of game experience they got and also 'cause and effect' (for example you need the key to be available if you're putting the door into the map, or from a plot perspective you can't go rescue a princess if she hasn't been kidnapped first). This building blocks can then be assembled into larger chunks, which can incrementally be built up into entire levels.

     

    That ought to balance out the need for new and random game play but still allow an element of design and sanity in the output, and you would get a bit of player customisation thrown in at the same time.

     

    If you are going to implement something like this though you need to be aware that there is a patent on this method of doing things which was initially targeted at editing video in real time, but a 'Media article' in that patent can be a game level and a 'media element' a level segment. IIRC level building was one of the examples given.

  15. Posted · Edited by sack-c0s

    To be fair removing directX or openGL won't gain quite as much as you imagine - it's a fairly lightweight layer and it hands a lot of code off to the GPU, which on modern chips is compiled or converted into native microkernel code that the GPU runs natively, along with a certain amount of optimisation. GPU developers have entire teams dedicated to this task alone. If an app is written properly is a one-time cost at initialisation anyway. You would lose compatibility though as you'd have to write everything for multiple GPUs.

     

    The only real losses come from the fact that you can't always do things in the best way for any given chip because on the PC your code has to run well on a selection of machines. You could take the view that it's best to optimise for the weaker chipsets but you'd still potentially be wasting the power and capability of the higher-end ones.

     

    In terms of powering down blocks of the GPU that shouldn't make quite a difference - I think a typical kind of timeframe for that to happen is around 100ms, which is about 5-6 frames, so it's not exactly going to drop out in the middle of a bunch of frames and slow everything down. I'm not sure about the CPU side of things though (although I have seen that if you don't sleep() then it ramps up to full speed and stays there for the duration of your program running).

     

    I can't share the power management vs performance figures I have here, but I will say that it doesn't actually make a major difference.

  16. Posted · Edited by sack-c0s

    both are valid (superFX vs 32X) - I just thought that the 32X way was preferable.

     

    If the price is down the users are up, and that ought to have a knock-on effect on the amount of software produced to use it

  17. Posted

    true - that was going to be my requirement as well - it has to be 'regular user-friendly'.

     

    But I was going to suggest something like the 32X because there's also the issue of price - limited-run retro expansion hardware is bad enough without having to build it into every individual cartridge so I was thinking that maybe the passthrough cartridge idea would be the way forward.

  19. Posted

     

    The line is where the chipset gets changed. It's more an "off" , when using more than one POKEY, than to use "unlimited" external memory. External Memory never has been a limit on the 8 bits. But, IF you exchange a chip, you get a different machine ...

     

    so let's imagine I do a SNES superFX style thing where the Atari polls input and puts it into an area of memory the expansion board can see, waits for a signal in an agreed memory location (such as an incrementing counter) and then throws the entire 6502 horsepower at pushing that video display and sound through the chipset.

     

    on the expansion board I have an ARM running at some multiple of the CPU clockspeed with its own internal RAM and a 3D engine running on it to run the game logic, filling the display buffer, spitting it out to common memory and then incrementing the synchronisation counter when the frame is ready.

     

    Is that still an Atari?

  23. Posted

    don't get me wrong - I did actually like that demo, but when I left my last comment I was watching it on my iPhone (so not the best keyboard in the world for writing long expressive comments) and was really knackered, so that pretty much explains my lack of enthusiasm.

     

    I don't think the transitions for the most part are anything special, but I do like some of the effects - I have an urge to play with rotozoomers now for some reason...

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...