Jump to content

pwwit1

Members
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

1,525 profile views

pwwit1's Achievements

Space Invader

Space Invader (2/9)

12

Reputation

  1. Nice work!! I started on a lynx project earlier in the year, came across this exact issue and wanted to redo the debugger with imgui!
  2. It's definitely seems like uncharted territory so far. Since there were no responses for a while, i had to figure out my own system creating a cart full of assets and how load them in at runtime. I finally managed to get it working! I'll quickly describe how it works and you can tell me what a terrible idea it is Basically all of my game sprites are located in an 'assets' folder (all of the *.spr files) I noticed src/cart/filler.py fills the cart with 0's, so I hijacked that to scan everything in the 'assets' folder and pack that data into the cart instead! Assets can either be aligned to multiples of __BLOCKSIZE__ for faster loading (but wasted space), or be packed together tightly. The packed cartridge is then run through "makelyx" to build a cart that works on device To track offsets withing the file, src/cart/filler.py also exports a header file with the #defines of the cart assets, their starting offsets and lengths. To load an asset from the cart in-game i use "lseek" and "read" with the #define of the asset to load. Assets are loaded with a wrapper function like this: load_sprite(FILELIST_0_NJ1STANCE1_OFFSET, FILELIST_0_NJ1STANCE1_LENGTH, ninja_frame_0); To help visualise what was going on, my tool-chain now displays a visual representation of the cartridge and the memory map: In the cart output, you can see the cart layout. Code is green, And each line represents a different file; you can see they are aligned to __BLOCKSIZE__ multiples. Now file loading is done, I still have to figure out how to load in/out code in a nicer way. Karri, i'd love to see your current RPG. I do struggle with parsing some of these makefiles though, i'm just not used to them after a career of using *.sln files in Microsoft Visual C++.
  3. Hello, I've been using the latest lynx programming template with great success, so thank you to everyone that has worked on it! Since there is so little memory I'd like to load/unload files from the cartridge. I thought that's what the template was doing at first, 'resident' stays in memory and loads modules as they are needed 'game' and 'intro'. On closer inspection, I don't think that's how it's working. It looks like everything is loaded into memory all at once. Is there a way to specify a cartridge layout, load files from the cartridge using the lynx programming template? There is a great section in the tutorial (https://atarilynxdeveloper.wordpress.com/2014/09/10/programming-tutorial-part-18files/) but i'm not sure how this applies to the template. I'm also at a loss of how the segments are laid out in memory. Looking at lynx.map, I can see the list of segments, their position in memory and sizes, but I cannot find where they are defined. Here is something i have been playing around with to figure out Lynx development, palettes, sprites etc:
  4. This works perfectly. Thank you! Just in case anyone is trying to setup a Lynx build environment from a clean Ubuntu install, the full steps are: Install requirements: sudo apt-get install git build-essential checkinstall Install the Atari Lynx tools and compiler: git clone https://bitbucket.org/atarilynx/lynx.git cd lynx/tools make -f Makefile.deb Check the installation worked: $ cc65 cc65: No input files Clone OldAtAtari's template: git clone https://github.com/oldatatari/template/ cd template make This should create a 'game.lnx' in the template/game directory! You can run game.lnx with an emulator, or on actual hardware. For an emulator, you can use 'Mednafen', to set it up: sudo apt-get install mednafen Mednafen requires a lynx boot image called 'lynxboot.img', you can find it online easily. Once downloaded, copy 'lynxboot.img' to where Mednafen requires it: cp ~/Downloads/lynxboot.img ~/.mednafen/firmware/ Now you can run your game.lnx with: mednafen game.lnx Hope this helps!
  5. Thankyou for the responses. Using the new repo worked like a charm
  6. Hello, I'm trying to setup a lynx toolchain again, and reading the posts here I used Karri's template and cc65 like so: 1. Installed dependencies with: sudo apt-get install git checkinstall mednafen 2. Removed my install of cc65: sudo apt-get remove cc65 3. Installed cc65: git clone https://bitbucket.org/atarilynx/lynx.git cd lynx/tools make -f Makefile.deb Builds and installs ok. 4. Grabbed the template from here: https://forums.atariage.com/topic/287147-is-10-fps-a-too-low-framerate-for-a-lynx-tile-based-game/page/2/ Builds ok and creates a cart/game.lyx But unfortunately it loads up to a blank screen. If i use the precompiled cc65 from the same forum post (cc65_14.09-1_amd64.deb) I can build and run template with no problems! There are no obvious errors when building cc65, so I'm at a loss as to what is going on. Does anyone have any suggestions, or am I trying to use an old toolchain? Thanks for any response Paul
  7. Hello, I'm having difficulty understanding how sprite stretching works. In the image below, these 4 sprites (Sizes: 40x40, 32x32, 16x16 and 1x1) have exactly the same tilt and stretch values, but the amount of stretch varies by the sprite size. I've noticed that the stretch value seems to be multiples of the sprite width, which is fine for 1x1 sprites as the stretch and tilt are equivalent at this size. This is a problem because the larger the image the less precision the stretch attribute has. It also seems to contradict the documentation, which says stretch is a 16-bit fixed point value that is added to HSIZE per scanline (Although it does say per 'unit size', maybe 'unit size' is the sprite width?) With 8-bits of precision I should be able to increment the stretch 1/256th of a pixel per scanline, but it seems to increment 1/256th * Sprite Width per scanline. Is this correct behavior, if so, is it possible to create arbitrary polygons with large sprites?
  8. Hello, I'm having difficulty understanding how sprite stretching works. In the image below, these 4 sprites (Sizes: 40x40, 32x32, 16x16 and 1x1) have exactly the same tilt and stretch values, but the amount of stretch varies by the sprite size. I've noticed that the stretch value seems to be multiples of the sprite width, which is fine for 1x1 sprites as the stretch and tilt are equivalent at this size. This is a problem because the larger the image the less precision the stretch attribute has. It also seems to contradict the documentation, which says stretch is a 16-bit fixed point value that is added to HSIZE per scanline (Although it does say per 'unit size', maybe 'unit size' is the sprite width?) With 8-bits of precision I should be able to increment the stretch 1/256th of a pixel per scanline, but it seems to increment 1/256th * Sprite Width per scanline. Is this correct behavior, if so, is it possible to create arbitrary polygons with large sprites?
  9. Cheers thankyou! Interestingly if I don't clear the high byte, in the emulator the math results always return 0xff. Using Handy
  10. Hello, I'm really starting to like programming the Lynx, what a great little platform! Recently I started to play around with doing simple divides with suzi, and they mostly work. Except when I have a remainder :\ So here is my little program that I test by inspecting the accumulator it reads the result in a debugger. It takes the decimal value 15 and divides it by 20. DCBA return 0, as expected ML, the remainder, returns 15 - which I find weird. I would expect the remainder would be .75 in 16bit fixed point (7FFF or something similar). Am I reading the remainder correctly? Code is below ; Divisor lda #20 sta SUZI_MATHP stz SUZI_MATHN ; LSB of numerator lda #15 sta SUZI_MATHH stz SUZI_MATHG stz SUZI_MATHF stz SUZI_MATHE SYS_SUZY_MATH_WAIT ; result lda SUZI_MATHD ; 0 lda SUZI_MATHC ; 0 lda SUZI_MATHB ; 0 lda SUZI_MATHA ; 0 ; remainder lda SUZI_MATHM ; Remainder is 15?! lda SUZI_MATHL ; 0 My question is is there any simple way to divide two numbers that give a fractional result (say 0.5) and use that to multiply another number? Something like 20 / 40 * 100 = 50. It seems so cumbersome using remainders to do this, I must be missing something. Any suggestions are welcome
  11. I'd love to, but it's rotating a 72x72 buffer that is generated at runtime!
  12. How does this work? I'm generating the image at runtime via suzy! This is the approach I've taken. Not sure how fast it will be on real hardware though. Trickier than I first thought because of the pixel packing, but it works. Not optimized at all either! My code is below: ; ; ==================================== ; sys_Copy3DScreenWithRotate ; Copes an area of 72x72 and transposes it ; ==================================== sys_CopyScreenWithRotate ldx #36; inner loop ldy #0 ; outer loop stz z_C ; stores the column ; backup dst address lda z_dst_L sta z_AL lda z_dst_H sta z_AH lda #0 sta z_C .copyline: lda z_C and #1 beq .drawLeft jsr plotRightPixel jmp .endPlot .drawLeft: jsr plotLeftPixel .endPlot: jsr sys_NextDstLine jsr sys_NextSrcPixel dex bne .copyline; ; Woo! Completed a line! ; Next destination source clc lda #44; adc z_src_L sta z_src_L bcc .L3 inc z_src_H .L3: ldx #36 lda z_C and #1 beq .skipY iny .skipY: inc z_C ; reset dest Plus next pixel clc tya adc z_AL sta z_dst_L lda z_AH sta z_dst_H cpy #36; we only do half the vertical lines bne .copyline rts sys_NextDstLine clc lda #80; Divide by two is because each byte is actually two pixels!! So to offset 160 pixels it's actually 80 bytes adc z_dst_L sta z_dst_L bcc .L0 inc z_dst_H .L0: rts sys_NextSrcPixel ; Next source pixel(16-bit add) inc z_src_L bne .L1 inc z_src_H .L1: rts ; Plot 2 horizontal pixels (left) plotLeftPixel lda (z_src) asl asl asl asl sta (z_dst) jsr sys_NextDstLine ; Second pixel lda (z_src) asl asl asl asl sta (z_dst) rts ; Plot 2 horizontal pixels (right) plotRightPixel lda (z_src) and #%00001111 ora (z_dst) sta (z_dst) jsr sys_NextDstLine ; Second pixel lda (z_src) and #%00001111 ora (z_dst) sta (z_dst) rts
  13. Hello, I think I know the answer to this, Suzi can mirror and flip, but does anyone know if you can use her to rotate a sprite 90 degrees? Something like this: A B C C F I D E F = B E H G H I A D G I could do it with the CPU, kind-of like a matrix transpose. If that is the only way to do it, what would be the best way to approach this (for speed) with a screen sized sprite? Appreciate any thoughts!
  14. This is really great! Thankyou I'm a little new to this, but is there any way to create breakpoints, view registers and step through the executing code?
  15. Received mine today! Fast postage, works perfectly, thanks SainT
×
×
  • Create New...