Started by db6128, 06:11, 06 December 12
0 Members and 1 Guest are viewing this topic.
Quote from: Devilmarkus on 14:04, 27 February 12Quote from: ukmarkh on 12:38, 27 February 12[The owner of one of the few existing cartridges of Chase HQ 2] mentioned to me that unless someone could find a way to guarantee the code wouldn't be duplicated to anyone else, he wouldn't be interested.Did he also say things like "My treasureeeeee" and is he a little grey guy?
Quote from: ukmarkh on 12:38, 27 February 12[The owner of one of the few existing cartridges of Chase HQ 2] mentioned to me that unless someone could find a way to guarantee the code wouldn't be duplicated to anyone else, he wouldn't be interested.
Quote from: db6128 on 04:47, 08 December 12Speaking of double-buffering, though, I wonder if anyone has an idea about this: when I have it enabled, there is slight flicker, seemingly between the two screens, at the bottom of the grid (only visible if it's populated at the time, of course). Why could this be? I can't think of anything I'm doing wrong that would cause it, but then I can't see why it would just happen either.
QuoteI've had a bit of a look at what I presume is the point you are doing the double buffering, and I think the problem is you have not waited for vsync with the swap to &4000 after your screen copy. [...] just before your code swaps to the screen at &4000 [...] the beam is not quite halfway through refreshing the monitor. More importantly, the CRTC is in the middle of displaying the current screen, and it will not reflect a change to the screen base address until it begins a new screen. So potentially, your code will go on to start modifying &c000 while the CRTC is still pointing to that area of memory for the current screen. I believe that is what is visible briefly at the bottom of the screen.
QuoteAlso, I hope you dont mind a comment on your screen copy. You have used a short LDI string, I guess because LDI strings are faster than LDIR? But your LDI string is too short if speed was the reason for using it. LDI is only 1 NOP faster than LDIR per byte, and with just 8 LDIs, you only have 8 NOPs saved in that loop compared to LDIR, but your loop structure with two counters is at least 8 NOPs by itself, so there is no speed gain with the LDI list that short. Although if I am not mistaken your copy completes with HL=&0000? If that's correct then a faster loop would be to replace both the A and IXH counter checks with LD A,H / OR A,L / JR NZ,Loop after your LDI string.
; simpleldir ; ~&7800x6 = 184324 NOPs / 184 ms; unroll x8; thus outer counter must be &7800/&100/8 = 15ldi ; 8x5 = 40 NOPsdec a:jr nz ; 4 = 44 x 256dec ixl:jr nz ; 5 * 15; = 44x256x15 + 5*15; = 169035 NOPs / 169 ms; unroll x12 (16 is not divisible into (&7800/&100)); thus outer counter must be &7800/&100/12 = 10ldi ; 12x5 = 60 NOPsdec a:jr nz; 4 = 64 x 256dec ixl: jr nz ; 5 * 10; = 64x256x10 + 5*10; = 163890 NOPs / 164 ms; Axelay's suggestionldi ; 16x5 = 80 NOPsld a,h ; 1or l ; 1jr nz ; 3 ; = 85 * 1920 = 163200 NOPs / ~163 ms
Quote from: db6128 on 17:09, 08 December 12So, you're now a contributing author! (Incidentally, even though there's no point changing back, I wonder if these would have been enough of a gain to stop the flickering, haha)
Quote from: db6128 on 17:09, 08 December 12Btw, as for unrolling, that's a pretty nifty CLS and memory clear at the beginning, right? It felt even more epic when there was just one gigantic contiguous area of memory to clear! But that layout had the corollary that my screen and data were not adjacent, meaning that I had to do two LDIRs per frame - so, out of a single-time loop and one that happens ever frame, it was obvious which one would have its way with my RAM layout.
Quote from: db6128 on 17:09, 08 December 12Really appreciate the great comments. In particular, it might have taken me a while, perhaps forever, to realise how I'd messed up the screen refreshing, so that's brilliant. Thanks a lot!
Quote from: Axelay on 10:42, 10 December 12 ...But I guess I'm hoping you eventually find a way to use both screens as buffers so that copy isnt needed at all.
QuoteYep, the SP is great for 'misusing'. Most or all of my previous projects feature using the stack in some way other than 'normal', Sub Hunter especially, though I didn't think of that particular approach myself, that came from Operation Wolf via a comment about it from arnoldemu.
Quote from: db6128 on 23:59, 10 December 12 See, the reason I don't use the screen as the buffer is that a simple on/off format is (theoretically) inefficient and also that I've planned to store various other things once I add more features/variations. I suppose that, for the simplest version where cells indeed can only be on or off (which I might find out is the only one that can run anywhere near fast enough!), it might be the case that the extra speed gained (again, theoretically) from the current type of storage is outweighed by the large copy, and so just using the screen(s) might be best. So now you've made me consider creating an alternative version to test that some time!Actually, sorry but I've already changed the branch after the LDIs - it's a byte shorter, 2 NOPs faster, and not dependent on the final address(es) to use JP PE,label instead.
Quotealways loved Life implementations
QuoteWow, it's VERY impressive, how fast this is! Maybe this is the fastest GoL-Implementation on the CPC we have ever seen?!
QuoteRealising a GoL-based Turing-machine on the CPC comes closer and closer!
QuoteI didn't look at the code, but I wonder:...- is it optimized for the 23/3 rule? (the original Conway rule for his Game of Life)- so is the rule "hardwired" or would it be possible to configure other rules?
QuoteThis summer I developed such an application on the Z80, too. It isn't optimized (and still bugy), and I only focused on the interface/options/figure library/rule settings/memory friendly etc.:
QuoteProdatron: I just saw in the list of related threads that you made a version of Life for SymbOS. Thanks for clicking Like on my one! I was seemingly able to compile your source using WinAPE, but SymbOS (2, disc version, WinAPE set to 64+256 kB) tells me that it is "not executable in the SymbOS environment". Is it only for the next edition? Anyway, keep up the good work on all of your projects! I hope I'm not too humbled when I do see your version.
Quote from: db6128 on 04:00, 12 December 12(update at end of post) Axelay: You'd think I'd remember this, having found out the hard way exactly the same before in my C(++) versions, but here goes: Copying to the future as you go along does not work, because obviously (again, only in retrospect) that'll overwrite cell 90 (for example) with old information after its future has just been altered by changes in cell 89, and so on. So, indeed, the entire buffer generated by the previous iteration has to be copied before one begins the next. I just found this out during my latest frenzied session of coding, which meant that work was a total a waste of time. Just like when I supposedly learnt the same lesson before!
Quote from: db6128 on 03:38, 12 December 12Rules for birth and survival are looked up from tables, so they could be totally changed if the user wanted.
Quote from: db6128 on 03:38, 12 December 12However, I find that Life itself doesn't work very well with rules other than Conway's original one - more evidence for how good a discovery it was, I think!
Quote from: db6128 on 03:38, 12 December 12On the other hand, perhaps my main priority is to add support for Generations, in which cells have a lifespan longer than 1: If their count of neighbours goes to a 'death-causing' level, they start to age until they reach their maximal age and die, but during ageing they stop being included in the neighbour-counts of other cells but do continue to occupy space, preventing other cells from being born there. It changes the dynamics a lot and enables many different rules, some of which are really good.
Quote from: db6128 on 03:38, 12 December 12Prodatron: I just saw in the list of related threads that you made a version of Life for SymbOS. Thanks for clicking Like on my one! I was seemingly able to compile your source using WinAPE, but SymbOS (2, disc version, WinAPE set to 64+256 kB) tells me that it is "not executable in the SymbOS environment". Is it only for the next edition? Anyway, keep up the good work on all of your projects! I hope I'm not too humbled when I do see your version.
QuoteThat's really good! As I could see Nich C. implemented it hardcoded (but that doesn't make a big difference for the optimization)
QuoteI never saw [Generations] before, this sounds really interesting!
QuoteDid you assemble the "App-GameOfLife1.asm" (which is somehow the "make"-file, which includes the other ones)? Anyway I will attach the actual version as single files/DSK/source codes.
QuoteMy version is clearly slower than yours one. I think the main reason is, I am using a bit-field instead of a byte-field. As my field is 64x64, only 512bytes (=64x64/8) are required for one copy of the field and 1KB for both fields together. But this makes it probably much slower, because of all this bit shifting/handling stuff.
QuoteThe average time for calculating one cell is about 145 NOPs - just for generating it in the new bitfield (without the graphic output).I wonder how much time is needed for the "core"-calculation of one of your cells?
Quote from: db6128 on 15:25, 12 December 12Axelay: I'm glad you've found it interesting! By the way, I've heard a lot about your games, so I'm going to repay the favour by checking them out tonight. Yep, we need to copy the most recently generated future to the present, so they're both now the same, and then compute (write) the new future whilst leaving the present (from which it's read) completely unchanged.
Page created in 0.120 seconds with 53 queries.