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

Sheddy

Members
 View Profile  See their activity

  • Content Count

    798

  • Joined

  • Days Won

    1

Posts posted by Sheddy

  1. Posted

    @ Sheddy

     

    You can always apply the same technique with a non-finescrolling display, like your Space Harrier. Just keep HSCROL = 0, but you'd gain the invisible buffer area.

     

    By the way, did you notice how my marioscroller is masked by PMg for the vertical buffer??

     

    I think there are some lines in the DList setup part of my program (151,152,153) with REMs in it.

     

    Take the REM away, and put a REM before the line in which address 560 is changed. Then you must see a gr. 0 screen without scrolling, but you see the buffers being drawed.

     

    -----

    mux

     

    I thought exactly the same. I'm already using widescreen in SH - but I'd get a couple of missiles back with the fine scroll on. (Still need some missiles as the screen is not tall enough to look right at normal width)

     

    I hadn't noticed the PMg - I'll have to have a closer look at how everything is working!

  2. Posted

    ATasm seems to assemble thing in address order, so I'm not sure you can change that.  You could assemble 2 files and then copy them together (one as raw - to lose the header), or use a hex editor?

    .

     

    Hoped that would be easier :(

     

    Just curious, but why would you want to see this at the end? The prog will still autorun wherever the $2e0 adress happens to be in the binary file - the $2e0 address just won't be the very last thing that's loaded, is all.

     

    Right for run ($2e0/$2e1) but what about init ($2e2/$2e3)?

    Guess i have to append the files than.

     

    Thanks

    Matthias

     

    Yep - INITADD won't work with ATasm if you use it like that. Guess most things can use $2e0 instead - or only call it in the prog after things are loaded. Maybe we should e-mail Mark Schmelzenbach about it though?

  4. Posted

    ATasm seems to assemble thing in address order, so I'm not sure you can change that. You could assemble 2 files and then copy them together (one as raw - to lose the header), or use a hex editor?

     

    Just curious, but why would you want to see this at the end? The prog will still autorun wherever the $2e0 adress happens to be in the binary file - the $2e0 address just won't be the very last thing that's loaded, is all.

  5. Posted

    Hi Sheddy.

     

    You noticed  :D , indeed I use LMSs on every line, but note also that I used Horizontal Finescroll enables in the LMS graphicstype command $54.

     

    When it's narrow screen, AND you enable finescrolling you have 4 characters extra on the left AND the right that are not displayed, so you have 32 + 4 + 4 = 40 bytes per line: Also note that Antic is designed in a way you can make buffer areas. Off course when you have a 40byte screen with finescrolling you'd have a 48byte screen without LMSs.

     

    Now, note that the LMSs of consecutive antic 4 lines (in my DList) are mapped at exactly 40 bytes away from each other. So the LMSs can be taken out when the principle is debugged. Only on the exceptional lines and the start of screen you'd need the LMS.

     

     

    I've been working on this game for years. I started in 1995 and in the passing years I now and then added data. At the time I didn't plan to add music, just some beeps. I wrote a leveleditor to speed up the development. Now ALL levels are done, and I must focus on coding.

     

    Now I found the atari community I have something to work for.

     

    -----

    mux

     

    Well Mux, thankyou for the lesson today - I had totally forgotten (or maybe never knew) that Antic retrieves more bytes when the fine scrolling is enabled! In fact I had to double check to make sure I could believe my eyes - and here it is, in De Re Atari - chapter 6. My well thumbed copy of "Mapping the Atari" doesn't seem to mention this at all. This is just such a great way of doing scrolling - and it looks like that was how it was intended to be done all along.

     

    I'm sure everyone here wishes you well on this project. I found the same encouragement here last year - After years of being "in the wilderness" with my project, it was like coming home to a warm reception. Only problem is, there's less excuse not to finish, now everything's in the open!

    • Like 1

  7. Posted

    Hi Sheddy,

     

    I'm terribly sorry. Try the link to the "better graphics" thread below. I've posted a message there on [Wed Aug 06, 2003 4:13 pm] from which you can download another ATR. It's a bootable DOS2.0 ATR, and it has turbobasic (type L <return> turbobas.sys <return>).

     

    After booting up turbobasic, open scrprinc.atr in drive 1 and bootsmp3.atr in drive 2, and just type the Turbobasic command:

     

    RUN "D:SCRPRINC.BAT"



RUN

    Don't forget to load an area. Hold start F4 when typing "RUN <return>".

     

    have fun  ;)  

     

    p.s.

    the bootsmp3.atr is the bootable com-file, like it will be on the final version, with the needed data optimizations: I can compress the leveldata further from 24 kB to 16 kB.

     

    -----

    mux

    http://www.atariage.com/forums/viewtopic.php?t=29511&postdays=0&postorder=asc&start=175

     

    Thanks, that works now. Silly me - of course I needed to have turbobasic to start with! Now to check it out. :D

  8. Posted

    Okay, here it is:

     

    There are 2 ATRs in the zip. It is actually the level-tester from my Mario game in Antic 4.

     

    put scrprinc.atr in drive 1 and bootsmp3.atr in drive 2.

     

    scrprinc.atr contains a turbobasic prog:

     

    type run "d:scrprinc.bat" to load the data and the program.

     

    When started the first time you MUST load a level, by holding start down (F4 in emulation). Enter an areanumber between 0 and 63. (drive 2 contains all the areas), other numbers might freeze you 8bit.

     

    When under emulation turn on Turbo (1500% speed) to speed it up, cause it's still just turbobasic, NO code.

     

    Scroll around in the levels (look f.e. at area 3, 13, 19, or 31), some of them are just horizontal. Most have horizontal and vertical scrolling. It doesn't stop at the boundaries, so expect some garbage.

     

    Bugs occur, when changing scrolling direction. I think it has something to do with the WriteBuffer part.

     

    -----

    mux

     

    Am I the only one having problems? All I get is boot errors with scrprinc.atr in drive 1. But bootsmp3.atr in drive 1 gets a nice super mario title screen - but crashes on F4.... :?

  9. Posted

    It's actually fairly easy to write stuff like this on the PC with Blitz BASIC - just time consuming...  ImageWire was written in Blitz and took about two weeks for what is essentially a very primitive conversion system, most of the work was making the user interface go.

     

    I've never had to write a proper interface before - all my converters run in MS Access with quite a sprinkling of VBA code - certainly won't get a full graphics editor with that very easily! Looks like you got good results with Blitz though, even if it was time consuming. Must check it out, thanks...

  10. Posted

    Heaven...Sheddy...

     

    Do you get the principle of my scrolling???

     

    Or is it still too vague??

     

    The exceptional lines, which need a copy are one of the two:

    -the line that is highest in memory, so it doesn't connect to another line on the high end

    -the line just before a 4kB boundary.

     

    So f.e. an Antic 4 screen needs 1 extra line, because line 24 is highest in memory

     

    f.e. Antic E screen needs 2 extra lines, because there's a 4 kB boundary in the middle, and a highest line in the bottom.

     

    I've written a turbobasic demo, that shows this. It still has a few bugs (as the principle isn't even perfectly clear for me  :D  )

     

    @ Heaven

     

    Did you solve the "Move_Window" error: BNE instead of BCC for incrementing a double byte???

     

    -----

    mux

     

    Hi Mux,

     

    I get it - and the exception lines to deal with the 4K boundaries idea is brilliant! But since I haven't tried it yet, I'm still wondering what happens on the left and right edges. Sure, I get that you put data in from the "hidden" column every line, but what about when things are halfway hard scrolled? Surely without LMS to include the "hidden" column or some way to hide the very end pixels you get half of what's on the next line down, or half of what's on the line above - rather than the data scrolling in smoothly from the "hidden" column. It's probably just my lack of understanding - I haven't done much scrolling in conjunction with the hardware scroll registers.

     

    Show us the demo already ! :D

  11. Posted

    Interesting POV...

    I would say, a Tool on the PC will make it easier to create stuff for the 8-bits....  

    But, you can only create 100% in graphics & sound on the real machine.  

    So ... maybe... a MCS(++) Title for Sheddy's Space Harrier can be converted on the PC and finalized on a full compatible A8 version...

     

    I bet Sheddy has finished his Space Harrier before a MCS(++) Title for it is done ;)

     

    :!: :!: :lol:

     

    Gunstar is a true purist,

    but I would think a PC tool fully aware of Atari limitations is going to be easier to work with from an Artist's point of view. A converter tool alone is not enough to take full advantage of MCS. But writing either of these suckers on PC is going to be the problem. I know I couldn't do it without picking up quite a few more skills on the PC.

  12. Posted

    surely you still need LMS every line to avoid an ugly mess on the sides?

     

    No, just the exceptional trouble lines. Let me make some demo pics soon, I've got a big load of homework now. Expect something tomorrow.

     

    It's not necessary to mask the sides. Just use a normal display, without any Missile tricks or something.

     

    -----

    mux

     

    Thanks - No need to rush :)

  13. Posted

    Still don't get how it could work Mux - you'll have to show us mere mortals an example!

     

    OK - I'm beginning to get it....I think.... :ponder:

    surely you still need LMS every line to avoid an ugly mess on the sides, rather than just a standard 40 byte screen, (one line straight after the other)? - or do we use widescreen so you don't see that? Waste some missiles to mask the sides? Or you have something more devious in mind, Mux ;)

     

    So the 4K boundary problem crops up this way - but if you know which part of memory it's going to jump "incorrectly" to, you can have that place in memory prepared so it will look right. Way to go, Mux.

     

     

    Nice effort Heaven - but my brain is not in debug mode today though :D And those strange psuedo op codes you use in xasm confuse my poor little 6502 head when it is working ;)

  15. Posted

    @ Sheddy

     

    I think Analmux is talking about about something like this? I wasn't quite thinking along the same lines to start with, but his idea should work out better

     

    Yes, that's a bit what I mean, except, you'd need 16 kB screendata. Nice pictures you made  :D.

     

    I thought about this method last weekend. It must be possible to do this in both directions, that's for sure. But I stepped off of this idea. It needs twice as much RAM.

     

    I'm working on a Super Mario clone, which plays in ONE load from disk with 40 big levels, so I had to minimize the amount of RAM needed for the screen. Though it's in charmode 4, I had just about 1500 Bytes left for the screen, so I'm using a different technique, which can be applied in Antic E too.

     

    It's based on some Display List hocus pocus, splitting the screen in a way you don't have to worry about the LMS bullshit. It's usable for both horizontal AND vertical scrolling.

     

    You know, when you make a scroller you MUST take care of where the graphicsline BEFORE the LMS-line ends. But I don't. I just make two identical lines in different memory locations to solve the problem. So for the exceptional lines there's always one copy somewhere else.

     

    The exceptional lines are not only lines before LMS but also at the line with the highest address, so the line after.... forget it, it's too complex  :D , I'll make some pictures to demonstrate this soon.

     

    It's kind of a complex way, but it saves the most time AND memory.

     

    -----

    mux

     

    Very intriguing

    Look forward to seeing how this works.. :D (Instantly some Q's arise...How can you avoid having almost 2 screens worth of memory set aside without having to do a large copy at some point???) Sounds clever!

     

    Hadn't really thought it all through to having double buffered software sprites...mode E - 30K - scary.

  17. Posted

    I think Analmux is talking about about something like this? I wasn't quite thinking along the same lines to start with, but his idea should work out better.

     

    Horizontal scroll:

    2 normal screen widths. Grey box is memory area. black box the visible screen. Change the LMS pointers every 16 pixels to next lot. Draw just ahead, and prepare the screen behind. Get to the end of the memory area, and wrap back to the start again. Shouldn't be any problems with 4K boundaries either :ponder:

    post-1211-1062458509_thumb.png

  18. Posted

    Mark,

     

    there's always the "Megacart" format - supports upto 8Mbits=1MByte=1024K in 64 16K banks, or the XEGS format, which supports the same, albeit not fully switchable, in 128 8K banks. 256KB is one of the possibilities for both.

     

    Much more info in the Atari800WinPlus help under "Cartridge images (CAR, ROM, BIN)" and Jindroush's

     

    As to how to actually physically build these things, I'm sorry I have no idea! Sunmark (Super Genius) are making Megacarts, so they may be able to give you some pointers. I believe they use just the one chip even for even the biggest carts.

     

    Nice work by the way - I can't believe how many games you've converted or made XL/XE compatible recently. Thanks!

  19. Posted

    Which aspects are you concerned about in particular, Steve?

     

    I haven't ever done this over a full screen, but some things spring to mind that may be helpful (hopefully) :ponder:

     

    Unfortunately there'll be a need to do a fair bit of copying screen memory around in these modes - unless you have loads of memory to waste.

     

    You can still hard-scroll over an area slightly bigger than the normal mode D/E screen - Just like mode 4, an LMS on every line. While that's happening you can be working on building up the next screen to display and hard scroll....could get awkward if the player decides, "hmmm, let's go back the other way" though - but of course you may not allow that possibility, and have a one way scroll.

     

    If you want any reasonable size of scrollable playfield area without using up loads of memory, you'll need to create your own "tiling" system - IE a kind of virtual character mode - Make all the background composed of blocks of a suitable size - say 8*8 or 16*8, and give 'em a reference number. Then you store the reference numbers and relative positions in a table, and get the drawing routine to scroll through it, and draw them at the appropriate time.

     

    It's a lot harder work to do than a character mode, and more CPU is required, but I expect a lot of the clever people here can figure out ways to greatly minimise that load (TMR has done a great side-ways shooter on C64 (which can't scroll the color attributes), so he must have thought about this a lot more than me!)

     

    The great thing is, you have complete flexibility over the size of the "virtual" characters this way - you can pick whatever size is best suited to the background requirements.

  20. Posted

    Here are some pictures I promised.

     

    Picture 1 shows how the sprites must be handled.

     

    The upper three are generated by circuit 2, the lower three by circuit 1.

    In the middle, where they overlap you see the resulting graphics. In fact this means that you can make sprites with a higher color-resolution.

     

    So when you just use sprites of circ. 1 you see 'transparant' sprites. This means that where they are used, the 2nd circuit (which only shows colors) output is mixed with the sprites.

     

    The other way round:

    When you just use sprites of circuit 2 you also see 'transparant' sprites. They again are mixed with the first circuits shade output.

     

    In other words: Players and Missiles of the first circuit don't have priority over graphics of the second circuit, and vice versa.

     

     

    Picture 2 shows some 64 color 160*192 res. graphics that can be displayed with the video extension.

     

    Picture 3 shows the process of building the graphics:

    3a: this is generated by circuit 1, that is the main circuit on the atari itself.

    3b: this is generated by circuit 2 in the extension unit. It shows the color-attribute cells.

    3c: the result of combining 3a and 3b.

     

     

    -----

     

    Another remark:

    The second video in the external extension unit has its own memory and databus, so doesn't need DMA, so doesn't slow down the CPU.

     

    -----

    mux

     

    Very neat, but spooky on picture 3 -

    I've just started messing about trying to do pics in exactly the same modes but on a standard atari, interlaced. Maybe it won't come off - but if I end up using it in a game, it would be easy to enhance and move over to this great upgrade.

     

    Oops, nearly forgot - put me down for a PAL version :D

  21. Posted

    If it's 30 or 60 kb, it's both too much data to handle for the CPU if you want to make fast changes.

     

    I figure for gaming purposes you wouldn't need to handle the whole screen, just certain ranges of lines. For images, you'd do the whole screen.

     

    -Bry

     

    Agreed, too much for the CPU to handle comfortably,

    but combined with a vast amount of storage - such as a megacart - it's quite possible to make graphics/soft sprites at least 30-50% faster than "normal" - so maybe less of a problem than you might expect.

  24. Posted

    Well here's another production of mine. You guessed it right, it's mario again. These are screenshots from some of my levels in debug-mode (no sprites/no playing). The main idea, graphics and all levels originate from 1995-1998. Then I finished highschool, started studying, but now I'm ready to finish the coding. The game will be available as freeware soon (possibly this year). It's still Antic 4 with flickering sprites, but I think it's a nice start for a beginner. It uses in fact almost the same spriteshapes from the SMPDEMO.

     

    -mux

     

    It'll be great to have some more modern platformers for the old 8-bit.

    Good luck with it!

  25. Posted

    Here's the problem:

     

    There aren't that many colours to choose from to give things their own unique colours.

     

    What we have at the moment is two standard 4 colour atari screens on top of each other to give 8 colours plus some "mixing" colours where pixels overlap. The choices in the current palette are in the pic below.

     

    You've got screen A and its colours at the top

    then in the middle, screen B

    and then + at the bottom is the result of mixing the A and B colours

     

    I should point out that where black mixes with another colour you get the impression of a darker version of that colour (surprise!). But if you just use a colour on it's own (ie with a "transparent" colour), you will get a strange seethrough semi-transparent version of the colour - that's why I have black available on both the A and B screens. The outlined boxes are the representations of the "transparent" or "background" colour, not white.

     

    The enemy is flicker in this arrangement - which happens when you get different brightnesses of colours on the A and B screens. For example any of the colours and black flickers worse than say, grey and green - because the grey and the green are the same brightness, but black has no brightness at all. (This is why I cannot increase the brightness of the colours too much, or the flicker because of the contrast with the black becomes worse and worse.)

     

    If someone can come up with a better palette with some more interesting mixing (based on the same amount of colours - 4 per screen) - maybe we can do better?

    post-1211-1060443411_thumb.png

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...