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

Lillapojkenpåön

Members
 View Profile  See their activity

  • Content Count

    486

  • Joined

Posts posted by Lillapojkenpåön

  1. Posted

    Some of the graphics in the 7800 basic samples are one line taller than what's going to be displayed, and have one pixel of all the colors used in the graphic on that extra line, I was just wondering if that's how the color 1-3 gets decided, in the order they are encountered from the bottom and probably left to right, if that's the case it would maybe be nice to have a checkbox option in the sprite editor to add that extra color index line when you select the size, if that's even why that line is there?

  2. Posted

    18 minutes ago, Defender_2600 said:

     

    In 320B mode, with Kangaroo mode enabled, it is possible to have 6 colors without restrictions (3 colors per palette) but you will have to give up transparency. However, in this case a great alternative would be to use the 160 mode. Here is an example:

     

     

    748666334_7800ShirusChase.thumb.png.7479be519fce6a3fbca08e53f90030d9.png

     

    DAMN!! I did start doing that, but I couldn't get the sprites to look good at all, your sprites look amazing!

    If you want to share the graphics or allow me to rip-off what I see, and don't intend to port the demo yourself,

    I can finish it in 160 mode.

     

    Where can I learn about kangaroo mode? I've never heard of it.

     

     

     

     

    • Like 3

  3. Posted · Edited by Lillapojkenpåön

    This is my first gamelike thing in 7800 basic, a port of Shiru's Chase for the NES

    It's not much of a game and I'm abandoning it, but great for learning 7800 basic

     

    It wasn't very well suited for 320B mode, the two restricted colors are barely used, and then you only have four left,

    I would have really liked one more color so the sprites could be solid and outlined with black instead of transparant in those place.

    Thanks for all the help everybody!

     

    EDIT:

    Not abandoned anymore, continued in 160 mode.

     

    7800-Chase.png

     

    LATEST

     

     

    • Like 8

  4. Posted

    Why doesn't this work? 

       incgraphic playerSprite16x16.png 320B 0 0 3 2

   incgraphic playerSprite16x16_2.png 320B 0 0 3 2



  frameCounter = frameCounter + 1

  if frameCounter = 60 then frameCounter = 0 : frame{0} = !frame{0}



   plotsprite playerSprite16x16 4 playerX playerY frame 2

     

     

    first frame is good, second frame is half frame 0 and half frame 1, like inbetween them, tallsprite options doesn't improve it

    putting the frames next to each other in one png doesn't work and putting them under each other in one tall sprite gives the same result as this.

     

    My zoneheight is eight and my sprite is 16 pixels tall.

     

     

     

  5. Posted

    hmm, something is weird, I'm using the same code that worked in my 160A project, but something is wrong with the numbers

     

    it works something like this for collisions with the foreground tiles

      

     const playerHeight = 16

 const playerWidth = 16



 const playerHeightMinusOne = 15

 const playerWidthMinusOne = 15



 const tileHeight = 8

 const tileWidth = 8



 const tileHeightMask = %00000111

 const tileWidthMask = %00000111



  



   if !joy0right then skipRight



   playerX = playerX + 1



   temp7 =  playerX & tileWidthMask ; how far into the current column are we



   x = (playerX + playerWidth) / tileWidth

   y = playerY / tileHeight

   charValue = peekchar( tilemap, x, y, 28, 28 )    ; top right

   if charValue > bgTile then playerX = playerX - temp7 : goto skipRight





   y = (playerY + playerHeightMinusOne) / tileHeight

   charValue = peekchar( tilemap, x, y, 28, 28 )    ; bottom right

   if charValue > bgTile then playerX = playerX - temp7



skipRight

    The constants are correct, and up and down seems to work as it should, but when going right as in this case, it's as if the maze is exactly twice as wide as it actually is, you don't collide with the right wall until you're way outside it, 

     

    I would have thought that the fix would be changing the tilewidth constant from 8 to 4, even though I don't get why when my tiles are 8 pixels wide, but that's not it, not only atleast..

     

    since I start plotting my tilemap 48 pixels from the left, do I need to take that into account with peekchar?

     

      plotmapfile tiledMap28x28.tmx tilemap 24 0 28 28     ; 24 = 48 pixels because doublewide, i think?

     

     

    I think it's some combination of those two things and the fact that I don't fully get things yet, like for example there still only seems to be 160 horisontal positions for sprites in 320 mode.

     

    oh with that in mind I just changed these

     const playerWidth = 8

     const playerWidthMinusOne = 7

     const tileWidth = 4

     const tileWidthMask = %00000011

     

    and it gives the correct collisions but offset by 48 pixels as I suspected, I'm gonna eat something and solve this before I even post my question..

     

    BOOM!

     

     const screenOffset = 24

     x = ((playerX - screenOffset) + playerWidth) / tileWidth

     

     

  8. Posted · Edited by Lillapojkenpåön

    Thanks for looking. Yes, when I said "graphics thingy" I meant block, those purple tiles in the maze should be dots so it's still not working right, I think they are not in the same block but I don't know what to do about it?

     

    This makes the tilemap display correct, but the text dissapear

     

      incgraphic newTiles8x8.png 320B 0 2 3 1 0

      incgraphic dots.png 320B 0 2 3 1 4

      incgraphic atascii.png 320B 0 2


     

      characterset newTiles8x8

      incmapfile tiledMap28x28.tmx

     

     ;characterset atascii

     alphachars ASCII

  9. Posted

    7 hours ago, Karl G said:

    Okay, maybe upload another code example? One of the smart people here may be able to figure out what's going on. Or possibly even me. :D

    It's the second time something similar happens to me, in my 160A experiment I had to do different characterset before plotting them, then it just started working with one, don't know what changed?

     

    320B source.rar

  11. Posted

    13 hours ago, Lillapojkenpåön said:

    Has anybody experienced the last row of each letter not being visable when plotting text, so that E looks like F, I look like a T etc?

    this is all the code related to the text

     

     incgraphic alphabet_8_wide.png 320B 0 2 3 3 4

     characterset alphabet_8_wide

     alphachars ' abcdefghijklmnopqrstuvwxyz.!?'

     

      plotchars 'abcdefghij' 4 20 0 10

    I used atascii instead, display correct,  but that turned my dot tiles into numbers, is that text to big so it pushes the dots out of the graphics thingy? How do I fix it?

  12. Posted · Edited by Lillapojkenpåön

    Has anybody experienced the last row of each letter not being visable when plotting text, so that E looks like F, I look like a T etc?

    this is all the code related to the text

     

     incgraphic alphabet_8_wide.png 320B 0 2 3 3 4

     characterset alphabet_8_wide

     alphachars ' abcdefghijklmnopqrstuvwxyz.!?'

     

      plotchars 'abcdefghij' 4 20 0 10

  14. Posted

    25 minutes ago, Karl G said:

    Here's a modified version of your example that reduces the width of the tile map to 30

    Do you know if there's a way to resize an allready drawn map, or if you can move big chunks of placed tiles on the map in tiled, those would be nice features

  18. Posted · Edited by Lillapojkenpåön

    14 minutes ago, SmittyB said:

    I would expect that to be because too much is being drawn in those zones, but it's hard to say.

    there's just my map and a sprite on the screen

     

    weird.a78

     

    the pacman mouth is also something weird, the sprite is just a solid square

  20. Posted · Edited by Lillapojkenpåön

    14 minutes ago, SmittyB said:

    Neither of those binaries seem to work for me on either BupSystem or ProSystem.

    That sounds not good, what's the A78 file? maybe that's the one I'm suppose to share?

     

    Thanks for all the valuable information, I appreciate it, I would have given up on myself a long time ago

  22. Posted

    Thanks, that's kind of how I thought about it, but then you wrote this

    3 hours ago, SmittyB said:

    You can enable 'doublewide' which tells the system to read 2 consecutive bytes at once, but of course that still only gives you a tile width of 8 pixels and not 16. (Doublewide would result in a tile width of 16 with the wider pixels of 160A however).

    Which indicates it also doubles the pixel width, I never noticed any pixel width change with 160A and having doublewide on or off, but maybe it's hard to notice, or only doubles it in 320 mode?

     

    I got my playfield displaying, but it stops drawing tiles near the right of the screen, does tiles counts as objects? It doesnt improve when I add more dlmemory, should be able to display 136 objects per zone it says

     

    320B.bin

     

    I just drew two lines across the screen, as you can see they stop at the same place

     

    • Like 1

  23. Posted

    2 hours ago, SmittyB said:

    Most of the limits for what you can draw including the width of objects are based on the number of bytes and the number of pixels you get for a byte changes based on the graphics mode.

     

    For 160A, 320B, and 320C a single byte will represent a 4 pixel wide slice of graphics with 2 pixels for 160B, and 8 pixels for 320A and 320D.

    This means that each 'tile' will actually be only 4 pixels wide.

    Hmm, I used to use 160A with doublewide on, and made my tiled maps with 8x8 pixels, so I assumed the 4 pixel character width was something under the hood I didn't have to worry about, and if I made wider tiles they just got split up somewhere along the way and would still appear on screen correctly.

     

    I was also a little confused about doublewide, since it didn't seem to change the pixel width when using 160A, only read 2 consecutive bytes at once, but maybe I'm wrong?

     

    But it sounds like you're telling me that if I want the finer resolution my tiles can only be 4 pixels wide, not 16 like now, I will try it

     

    2 hours ago, SmittyB said:

    try 'plotsprite newTiles16x8 0 0 0' to see if that draws anything. If it does there's probably something in the mapfile that needs adjusting.

    Thanks, atleast something on screen

     

  24. Posted

    34 minutes ago, SmittyB said:

    You get palettes 0 and 4 plus background/transparency (taking into account the quirks with transparency in 320 modes).

     

    Thanks!

     

    Is there some limits with tile width? I made 16 pixel wide ones and nothing shows up, just a blcak screen

     

      

      set romsize 128kRAM   ;extra 16k of RAM from $4000-$7fff.

  set zoneheight 8

  set doublewide off

  set screenheight 192

  set tv ntsc

  set dlmemory $4000 $4fff 

  set basepath gfx



  displaymode 320B 



 bank 1



 P0C1 = $a2 

 P0C2 = $a6

 P0C3 = $aa



/*

 P1C1 = $52

 P1C2 = $56

 P1C3 = $5a



 P2C1 = $c2

 P2C2 = $c6

 P2C3 = $1a



 P3C1 = $0f

 P3C2 = $00

 P3C3 = $00

*/



 P4C1 = $a2 

 P4C2 = $a6

 P4C3 = $aa



 incgraphic newTiles16x8.png 320B 0 1 3 2 0 




  characterset newTiles16x8

  incmapfile tiledMap16x8.tmx





  clearscreen

  plotmapfile tiledMap16x8.tmx tiledMap16x8 0 0 20 24

  savescreen



mainLoop



  ;logic here



  restorescreen 

  

  ;plot here

  

  drawscreen



 goto mainLoop thisbank



 bank 2



 bank 3



 bank 4



 bank 5



 bank 6



 bank 7



 bank 8

     

  25. Posted

    2 hours ago, Mord said:

    I suppose one way to describe it is that a 320 mode is basically a 160 mode as far as placing sprites are concerned, but each sprite has the fat pixels broken up into two halves with regards to their color. (ie: "pixel pair") 

     

    In 320B in particular both halves of the pair have conditions for being displayed.  Specifically in order for the C1 palette entry to display, it must be paired with a C2 or C3 for the other half of the pair. If you try to have a pair C1's or a C1 + BG, both halves end up being the background color. C2 and C3 can be displayed freely.

     

    Also, if you're playing with 320B, make sure you aren't testing in ProSystem. It doesn't understand the palette condition above and will display C1 freely like C2 and C3. Real hardware, A7800, and BupSystem (fairly certain about Bup but haven't tested personally) will display with the rule above.

     

     

     

    Thanks now I get it! That's alot less restricted than I thought

    I also read you only have 7 colors

    so is that palette 0 and 1 + transparant?

     

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...