José Pereira Posted November 13, 2012 Share Posted November 13, 2012 (edited) @JAC! That's a definite possibility. Rybag's reduced HSCROL DMA technique leaves lots of extra cycles. The four players could even have different gradients. Or the players could be overlapped for 3-color mode if the hero width is reduced. I am not a great artist though, so I'd need work with somebody on that. Xuel on the game the guy it's PMGs only or you have also soft sprite using BACKGROUND (00) Black? (What are the bit-pairs of Red, Green and Blue?) This is so C.P.U. use that I think you are in trouble to have enemys, shoots, explosions,...? About enemys, their explosions, coins rotation,... they seem pre-fixed at the same places, right? Then for here maybe not hard to have them as soft sprites only. But for our guy? Even if we, in some way get it as PMGs only (squeeze, change,...) we still need to have it's shoots as soft sprite.Have all guys (including ours) as soft sprites are C.P.U. out of question/impossible? My idea is if you go my idea and have the sky all high Blue then I can have the contour of our guy as Black and his Eyes using the Blue of the sky and PMGs in different colours maybee possible to colour the guy using PRIOR0. That's why, if you think it's possible our guy as soft sprite then I really need to know of wich bit-pair are each of the colours? (and also have definitive colours and luminances for the PRIOR0 Oring) Edited November 13, 2012 by José Pereira Quote Link to comment Share on other sites More sharing options...
José Pereira Posted November 13, 2012 Share Posted November 13, 2012 Just saw you're Xuel. Did you understand my questions? Quote Link to comment Share on other sites More sharing options...
Xuel Posted November 13, 2012 Share Posted November 13, 2012 @Heaven I'll post about the X/Y movement soon. See also. @José Pereira The current chromas are blue 7, red 3 and green 13. I'll try your suggestions tonight. The demo has no soft-sprites. The hero consumes all four players and all four missiles at the moment. Now that the players are solid some of the missiles could be used for other purposes. If you don't mind background showing through the eyes and details or if 3-color players are used, then all missiles could be used. Also, DMACTRL/PMRez could be set to double-line to halve the sprite memory footprint. There are about 23 character set slots in the current tile-set that are repeats of the sky. With some complication to the tile renderer, they could be freed up for soft-sprites. That doesn't give a whole lot of detail for enemies but it could be done. Consider that the hero currently covers the equivalent of about 88 character set slots since he's 32x44 effective pixels. The tiles could be reduced to 2x4, 4x2 or 2x2 tiles to free up more slots at the expense of background detail. Fancier soft-sprites will probably require dropping the frame rate. Back to the original topic of the thread , the line-by-line color swapping does hamper the CPU quite a lot, though less severly when using your swap-only-two-colors scheme and assuming some computation can be snuck into the raster period either by manual threading or by timer IRQs without degrading music/sfx too much. I'm sure with some creativity, some balance can be struck that gives some more interesting results. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 13, 2012 Share Posted November 13, 2012 Xuel... Just going through the code.., Jesus, another dasm/mads heavy user need to look closer at the table generator. Btw. The code lines with >>> are what? Remarks or are they doing something? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 13, 2012 Share Posted November 13, 2012 I mean xasm Quote Link to comment Share on other sites More sharing options...
Xuel Posted November 13, 2012 Share Posted November 13, 2012 @Heaven Haha! xasm is the best. No I just got used to it and it's very fast which helped when assembling those huge movies I did. The >>> lines are interpretted as Perl. All other lines are interpretted as print "TEXT" in Perl. See the Makefile. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted November 14, 2012 Share Posted November 14, 2012 (edited) @Synthpopalooza Nice suggestion. Here you go: tiles-ntsc-synthpopalooza-lineshift.xex I don't know how it works since I didn't do anything to swap chroma/luma on alternate frames. I just prepended an instruction slot to the display list and swap between $20 and $30 every frame. Maybe some missed WSYNC deadline just happens to delay the kernel by a line on the appropriate frames because of lower DMA on blank lines? Probably could get rid of the gray line on the top if I really studied it. Suggestion: Add a DLI to the 96 instruction, that might fix it. So you will swap between 112, and 128+96 This technique is one I used when I was experimenting with alternating Graphics 15 and 10 every scanline. In that case, I had an effective resolution of 159x192 at 30 colors but with some flickering it seems. Used here though, it basically gives you the 160x96 resolution at 16 colors, but with no scanlines. There will be a few chroma and luma artifacts along the top or bottom of individual pixels but they are barely noticeable. And this is a great alternative for NTSC users (where PAL mixing does not work), as the higher refresh rate means the flicker is hardly noticeable. Under Altirra it's best to use frame blending as the picture jumps if you don't. It should work really well on a real NTSC Atari (I haven't been able to test it though). Edited November 14, 2012 by Synthpopalooza Quote Link to comment Share on other sites More sharing options...
Creature XL Posted November 14, 2012 Share Posted November 14, 2012 With a Timer IRQ in this situation the only way to save is by having it as the only possible source (to save having to test status bits), and have the OS Ram switched in so the vector can be taken directly. Yep, that's how I did it. @missing sound channel: Playing 8KHz (or even 16KHz) digis comes almost for free. At least low notes should be OK. I am thinking about PWM-style basses. Tests pending... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 14, 2012 Share Posted November 14, 2012 almost for free? Creature can you give me an example how to setup raster IRQs? a simple demo? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 14, 2012 Share Posted November 14, 2012 @Heaven Haha! xasm is the best. No I just got used to it and it's very fast which helped when assembling those huge movies I did. The >>> lines are interpretted as Perl. All other lines are interpretted as print "TEXT" in Perl. See the Makefile. ok... how does the VI-lookup table looks like? I am not into Perl. Quote Link to comment Share on other sites More sharing options...
José Pereira Posted November 14, 2012 Share Posted November 14, 2012 (edited) O.k. sorry but need to add more things to this post. So right one comes next---> Edited November 14, 2012 by José Pereira Quote Link to comment Share on other sites More sharing options...
José Pereira Posted November 14, 2012 Share Posted November 14, 2012 (edited) O.k. if my idea of changing just two colours reduce many cycles then there's still one more possible thing to do: It seems you have: each Tile as (4bytes x 32 scanlines) and Playing Area has (7Tiles high = 224scanlines) then what about reduce the number of visible scanlines for the Playing Area? I know that not many as you'll get small window to play but, if not 7Tiles high then 6Tiles high would be 192scanlines OR 6,5Tiles high that are 208 scanlines. It seems not so bad, at least the 6,5 Tiles high. For a (6,5 Tiles high = 208scanlines) you would get more Blank (16scanlines x 114) = 1824 cycles more 114 x16 ------- 684 +114 ------- =1824 That are about more 90bytes for soft sprite AND/LDA/STA/OR This 1824 with more only the two colours changes more about 1500cycles less for 208 scanlines that are about 3300cycles for free more that are 165bytes of soft sprite. I think that if we want something on this Mode get into 224 or aproximate the 240scanlines of A8 visible screen Area will reduce greatly the game be possible (this or any other with even less or less sized sprites). That's my opinion and have 208 or 216 or 224 doesn't seems a great difference (and you have to think that even 224scanlines for the Playing area then I presume you will have the others 16scanlines for a Status Area that even in ANTIC4 1Kb=1Charset will also need some cycles). P.s.- The guy sprites it's 'in the making', just wait untill weekend for at least one or two frames and my idea (it seems possible to have the guy using 4Players in Multicolour and (Eyes more Pants) in 5th Player 4Missiles PF3 colour... just 2or3 pixels width reduced, all PMGs starting at same xPos and just need two DLIs VCS like to change two Players colour Register at scanline(s) at the middle of the guy (or maybe not)). Edited November 14, 2012 by José Pereira Quote Link to comment Share on other sites More sharing options...
Tezz Posted November 14, 2012 Share Posted November 14, 2012 Playing 8KHz (or even 16KHz) digis comes almost for free.At least low notes should be OK. I am thinking about PWM-style basses. Tests pending... I'd be interested to see that too. The kernel I wrote earlier this year with a mode2/4 display had a 7.8Khz sample played every two scanlines. Quote Link to comment Share on other sites More sharing options...
Xuel Posted November 14, 2012 Share Posted November 14, 2012 @Synthpopalooza I have interrupts disabled so AFAIK adding a DLI wouldn't have any effect. @Heaven The comments are a little misleading. There are actually two tables for X movement. The first (veldirtable) is 256 bytes and is indexed by the facing direction (1 bit), the right/left bits of the joystick (2 bits) and the signed velocity (5 bits). Every frame, the old value (veldir) is ORed with the new joystick bits and used as the index to find the new value which has the joystick bits zeroed out ready for the next ORing. See here. So the table encodes a state machine or DFA that yields the new facing direction and velocity every frame given the old facing direction and velocity and the new joystick inputs. The logic of the state machine can be seen here. The Perl code just iterates through all possible input states and computes the output state for that table entry. The logic is as follows: Add one to the velocity if the joystick is held right but clamp at 15. Subtract one from the velocity if the joystick is held left but clamp at -15. Subtract one from the velocity if the joystick is neutral and the velocity is positive. Add one to the velocity if the joystick is neutral and the velocity is negative. Steps 3 and 4 simulate friction, though they act even when midair so that's some rough air! The second table (veltablelo/hi) is 32 entries and is indexed by the signed velocity component of veldir to scale from a -15 to 15 range byte to a -16 to 16 range word. The result of this table is added every frame to xpos. This makes the fastest velocity scroll by exactly one character per frame since xpos is divided by 16 to get the coarse scrolling component. Note that the vel component of veldir is actually 0 to 29 and is shifted to -16 to 16 by this table. veltablelo :31 dta [#*16/15]-16 veltablehi :31 dta [#<15]*$ff For Y movement, there is a 69 entry ballistic trajectory table which encodes the y offset in screen space, so negative of normal graphing direction. The highest entry is the start of a jump. The apex of the jump is at entry 51. The entries below that are free fall with a terminal velocity of 1/2 tile per frame. The terminal velocity insures that collision detection doesn't miss any coins or platforms on a fall from great height. Here's a plot: I just noticed after making that plot that the terminal velocity happens too soon which explains why the jump looks a little messed up when you cross that derivative discontinuity in the table. Anyhow, when the hero is on a platform, the jcount index is set to the apex and the ground offset is set to the platform height. Every frame the jcount is decreased. If a collision with a platform is encountered, then jcount is set back to the apex and the ground offset is set to the current jump height modulo tile size. So, the hero is always falling even when at "rest", but he is readjusted back to standing still before any visual updates if he falls through a floor. If you move off a platform in the X direction, then you really do start falling because there is nothing to block you and jcount just keeps decreasing. When you jump, the jcount is set to start and the jump height of 3 is subtracted from the the ground offset. Y blockages are ignored for jcount values between start and apex. This lets you pass through floors on the way up but not on the way down. jcount can never reach zero because the map height is only 16 so you'll always fall into a pit before you get there. @José Pereira Indeed reducing the visible height frees up CPU cycles, so that's definitely an option. That's what I did to get NTSC working. I just need to come up with something useful to do with the extra cycles now. Looking forward to putting your sprites in! 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted November 14, 2012 Share Posted November 14, 2012 almost for free? Creature can you give me an example how to setup raster IRQs? a simple demo? Well, it's not xasm/mads. Instead its ca65 with macros of my own. This is the first code I did. Meanwhile, it's a bit more But, as said, lots of more to experiment. HAR'em holds me back right now. Currently, I have two ISRs. One for color lines and one for lum-lines. So each ISR sets teh addr of the other. This costs some cycles and IFF one uses samples one could use 8KHz timer (set freq to 1 instead of 0) and does it like that: 1.) set color values 2.) play sample 3.) pre load regs again 4.) (maybe sta WSYNC) 5.) set lum values 6.) RTI Not tested, but sounds plausible. If I am missing something just tell me. ; Disable OS-ROM and IRQs. jsr disableROM sei movei 0,IRQEN ; Set addr for ISR. ROM disabled! movei_w irq_isr,$fffe ; Set frequency. movei 0,AUDF2 ; Set POKEY freq to 15Khz ( each scan line) movei 1,AUDCTL ; Set to desired cycle in scan-line sta WSYNC movei 0,SKCTL wait 98 ; <-- maybe some changes here movei 3,SKCTL sta STIMER ; Enable timer 2 IRQ movei 2,IRQEN cli ; done : jmp :- irq_isr: pha ; Reset and re-enable timer interrupt. movei 255-2,IRQEN movei 2,IRQEN ; color changes col_1: lda #0 sta COLBK col_2: lda #0 sta COLBK col_3: lda #0 sta COLBK pla rti 2 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 14, 2012 Share Posted November 14, 2012 thanks, Xuel. as being years ago in pro games biz as manager (now doing e-commerce stuff) I realise that you seem to have more experience than only touching A8 for first time. where is your experience coming from? really only from A8 coding? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 14, 2012 Share Posted November 14, 2012 Danke, Creature... need to look into it. Quote Link to comment Share on other sites More sharing options...
Xuel Posted November 14, 2012 Share Posted November 14, 2012 @Heaven I did a two year stint at a game company a few years ago. I've lurked around the demoscene since '93. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 14, 2012 Share Posted November 14, 2012 (edited) aha... let me think of Austin... hmmm... Activision Blizzard? Bioware? NCSoft? SonyOnline Entertainment? Zynga? just to name a view "smaller" companies based in Austin... interesting... seems to be a gaming melting point Edited November 14, 2012 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Tezz Posted November 14, 2012 Share Posted November 14, 2012 (edited) Xuel. Great to see a professional approach to game development. @ Creature XL. Attached is my display/sample play kernel from the intro of a game conversion. With this procedure I reduced the resolution of the ripped sample data down to 7.8Khz to play at the correct rate over 2 scanlines. I'm intending next to play at 15.6khz every scanline. I've attached a non kernel example so you can hear the original sample before the resolution was reduced. This should be how the final procedure will sound. welcome.xex welcome - original sample - nmi skipped.xex Edited November 14, 2012 by Tezz 2 Quote Link to comment Share on other sites More sharing options...
José Pereira Posted November 14, 2012 Share Posted November 14, 2012 Anyone here at RedRatSoftware in the old defunct/dead Fennel street 11 because this is real the worth of... The real old school! Just kidding!... Quote Link to comment Share on other sites More sharing options...
Xuel Posted November 14, 2012 Share Posted November 14, 2012 @Heaven It was XLGAMES, a startup led by Jake Song of NCSoft fame. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 15, 2012 Share Posted November 15, 2012 @Tezz thanks for that... and thanks for not mentioning that sample got played when pressed space bar 1 Quote Link to comment Share on other sites More sharing options...
Tezz Posted November 15, 2012 Share Posted November 15, 2012 oops! yea it would have helped to mention that Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 16, 2012 Share Posted November 16, 2012 first I thought it does not run properly in Atari800Mac Emu. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.