--- Log for 12.04.104 Server: truong.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16p1 Started: 1 month and 29 days ago 00.00.00 # That Win32 sim is really a bizarre thing - now it compiled without error, but uisw32.exe still shows the same behaviour as in my first try. 00.00.20 # it's dying in either CreateThread() or app_main() 00.00.30 # i am having problems also 00.00.36 # on 2 machines i have tried it 00.00.54 # anyone know if this death has happened in the last few days? 00.01.02 # BC, yes 00.01.09 # can you be more precise? 00.01.17 # we can check the builds :) 00.01.21 # i used a older source tarball, and it worked fine ( iused the oldest on the list) 00.01.42 # so we have the offending code in tarballs - that's a damn good start 00.01.51 # Don't know, this is my first try to get the sim running. 00.02.13 # rockbox-daily-20040406 is what worked fine for me 00.03.18 # okay - I'll take 0410 - diddy, you take 0409, and ami, you take 0408 - cool? 00.04.40 # Will give it a try. 00.04.41 Quit AciD (Read error: 104 (Connection reset by peer)) 00.04.42 # ermm o ne sec 00.04.47 # i have no cygwin 00.04.54 # give me 5 minutes to get cygwin setup 00.05.02 # so how do you know todays source fails? 00.06.29 # because i was at hme when i tried it 00.06.32 # *home 00.06.37 # ahaaa 00.06.38 # at in a library now 00.07.39 # Compiling... 00.07.54 # noticed "making an sim directory" when I typed make - wonder if the other fixes were implemented? 00.08.06 # s/make/configure/g 00.08.51 # 20040408 gives the same behaviour (for me). I am wondering if I'm doing something wrong? 00.09.05 Join ILuvit [0] (ILuvit@ool-18bc45af.dyn.optonline.net) 00.09.29 # Trying 20040406 (which worked for diddystar5) 00.09.30 # Hmmm, problem is I am using a different dev kit from others :( 00.09.46 # 0406 worked for me also 00.09.55 # ami, is your source code in the right dir? 00.09.56 # my cygwin install done 1 sec 00.10.12 # your local lib lets you install cygwin - coooooool 00.10.37 # 0410 GPFs 00.11.11 # trying 0407... 00.11.12 # well i'm not supposed to, but i found a linux boot cd that lets you remove the admin password :) 00.11.18 # 0407 GPF's for me 00.11.21 # ohh you are the one that told about that BC 00.11.49 # arghh forgot to get the make package 00.11.51 # one sec 00.12.02 # LOL - you bad bad bad boy - LOL 00.12.23 # solution is disable "boot from floppy" and then password the BIOS 00.12.26 # 20040406 works for me - so at least I'm not doing something wrong :) 00.12.37 # cool 00.12.50 # compiling... 00.12.50 # Trying 20040407.. 00.13.06 # just typed "make" for 0407 00.14.28 # 09 is bad 00.14.43 # we're down to three 00.14.44 # :) 00.15.10 Quit methangas (" HydraIRC -> http://www.hydrairc.com <- irc client ownage!") 00.16.17 # 20040407 is bad for me - so some change from '06 to '07 apparently broke the Win32 sim. 00.16.32 # need a faster machine - lol 00.17.00 # It's merely a 1.5 GHz Centrino notebook... 00.17.05 # yep 0407 is dead for me too 00.17.08 # same for me 0406 works, 0407 GPF's 00.17.10 # i have a duron 600 00.17.14 # this libray has nice machines :) 2.4 ghx and 19" monitors 00.17.34 Join hardeep [0] (1098@208.247.65.237) 00.18.32 # Hmm, only 2 changes on 6 April: convbdf.c and lcd-player-charset.c 00.18.38 # all the sims (not just win32) are broken because of the convbdf.c change 00.19.07 # Since changing lcd-player-charset.c should influence a recorder sim at all, it's probably convbdf.c 00.19.30 # the structures are now being declared const and then we're trying to memcpy to them 00.20.05 # hardeep: The strange thing is: Win32 sim is broken since 20040407, but X11 sim is working for me from current CVS!? 00.20.13 # amiconn, it crashed before the convbdf thing i think 00.20.37 # amiconn: hmmm, X11 sim just crashed on me 00.20.39 # latest cvs 00.20.53 # Btw: trying X11 under cygwin's X11 00.20.55 # diddystar5: it's the convbdf thing, i just debugged it 00.20.58 # me too 00.22.36 # i tried debugging in my msvc++, didnt show me anything 00.23.00 # I went the "printf" route - lol 00.23.12 # you need to use gdb if you build using mingw 00.23.23 # or you can build the msvc project with which you can debug from msvc 00.23.29 # hardeep: Why does the sim mecpy() to the font structures while the target doesn't? 00.23.43 # *memcpy() 00.24.02 # amiconn: target does too 00.24.06 # ohh 00.25.05 # amiconn: but, according to Linus' comment, the const flag just moves the data to .rodata from .data, where I guess you're still allowed to memcpy into 00.25.06 # If the target also memcpy()'s to structures declared 'const', then 2 questions arise 00.26.02 # (1) Why does the target not crash on it (well, maybe because it has no memory protection) 00.26.30 # (2) Why are these structures declared const in the first place, since they are not really const? 00.26.56 # amiconn: 1 is just like you said, no memory protection 00.27.11 # and 2 is the reason described in Linus' comment: move to .rodata on the target 00.27.47 # Doest this have any advantages? I cannot imagine what it should be... 00.28.17 # ..only that it adds confusion... 00.28.22 # I have no idea either... maybe to save .data space? 00.28.42 # plugins and sound settings is still broken :( 00.29.32 # is->are 00.33.13 # Did compile the X11 sim again from current CVS - still works for me (no crash) 00.35.04 # Is it correct that the sim does not save settings? 00.35.25 # the sim does save settings 00.35.33 # on x11 and win32 00.35.57 # i think the save files is sector32.bin or so 00.36.54 # amiconn: stramge, it's crashing on my system at the font location 00.37.11 # amiconn: did you rebuild the latest version of convbdf? 00.37.24 # Oops .. maybe I deleted that sector3D.bin file after trying to compile the Win32 sim. 00.37.44 # hardeep: yes I did. 00.38.23 # must be the position of the Sun or something then. :) 00.38.57 # how do i debug using gdb? (i just got it now) 00.39.01 # It's still running ... on Win XP pro 00.39.21 # yep, same for me 00.39.28 # (os that is) 00.40.01 # The X11 sim is really ugly to use with cygwin, especially since I am using a laptop (which has no separate numeric keypad) 00.40.48 # amiconn, to use x11 sim on cygwin, do you need the xfree86 stuff? 00.41.13 # amiconn: yeah, I only use it to make sure I didn't break anything on it. I much prefer the msvc project for debugging 00.42.27 # I don't have msvc, so I tried building the Win32 sim with cygwin (that works for 20040406, but not for newer source). 00.43.27 # ami - careful, although it runs on 0406, you will still need to patch it up a bit to get the features on it going 00.44.16 # er, not really... which features don't work on the win32 sim? 00.44.19 # diddystar5: yes (xfree86) 00.44.28 # mas3587 00.44.31 # plugins 00.44.37 # uhm, plugins work 00.44.41 # maybe still some others also - I did not try them 00.45.06 # what do I have to do to make them work after I type "make"? 00.45.28 # they don't compile for you? 00.45.44 # select plugins on the menu and (tm) happens 00.45.58 # I will check if they were compiled now... 00.46.13 # well, that's different... the plugins are not in the expected location. however, if you browse to them and select PLAY they'll still work 00.46.35 # BC goota move thoise to .rockbox/rockcks for that you know? 00.47.16 # wonder why MAKE can't do that? 00.47.37 # only about 50 keypresses to get to the plugins :) 00.47.53 # sure, make can be modified to copy them to the correct location 00.48.10 # but you were saying they weren't working which is incorrect 00.48.15 # Yes, but it is not allowed to be included in the CVS 00.48.19 # How do I set the "virtual root" for the Win32 sim. It sees the root of my C drive as its root.. 00.48.42 # you can't - the mod was rejected 00.49.23 # But the X11 sim uses that "archos" dir as its root... 00.49.57 # amiconn: how is "minesweeper" coming? 00.50.14 # i think the simulators need to be made the same (or close) 00.50.23 # they are way to differnen't 00.50.48 # I think getting them both working would be a good start :D 00.51.14 # i wonder if we can make 1 source tree for both the x11 and win sim's 00.51.19 # that would be best 00.51.26 # hhahahahaha 00.51.53 # certain core routines need to be diffferent 00.52.22 # elinenbe: Did not even start to write it .. I have to find a way to squeeze as much "cells" on the display as possible. 00.52.52 Nick c0utta{breakfast is now known as c0utta (~c0utta@200.cust47.nsw.dsl.ozemail.com.au) 00.53.41 # amiconn: scrolling display :) 00.53.54 # elinenbe: With too few cells it would be too easy to solve, while scrolling would be very confusing. 00.55.14 # magnify the cells around the one which is currently in view 00.55.55 Nick BC is now known as BC|NeedsFood (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 00.56.17 # If I use 7x7 pixel cells I can fit 8x16 cells (one status line), which is just between "easy" (8x8) and "intermediate" (16x16) level of the original. 00.56.57 # If I play the original, I mostly use the "hard" level, which has 16x30 cells. 00.57.42 # so you guys reckon it's convbdf.c that's caused the issues with the sim builds ? 00.58.01 # c0utta: yeah, just about to submit a fix 00.58.04 # haha bc 00.58.29 # goody 00.58.33 # wierd - i have source as of 31-Mar abd have been "cvs update" every day 00.58.43 # s/abd/and 00.58.49 # no problems here 00.59.05 # c0utta: you're probably not rebuilding the tools (convbdf specifically) 00.59.09 # c0utta: the tools are not recompiled automatically. 00.59.24 # true - i'm not building the tools 00.59.30 # should i ? 00.59.43 # if you want the sim to crash :) 00.59.59 # hahahahahahahahahahaha 01.00.01 # try "make clean" then "make" in the tools dir - then rebuild the sim -> crash. 01.00.02 # a "feature" 01.00.02 # if i leave, its because windows crashed brb 01.00.23 # LOLACCCCCCCCCCCCS 01.00.37 # ok, windwos didnt crash :) 01.01.13 # windows* 01.01.39 # s/windwos/windows/ 01.01.48 # took long enough 01.03.26 # elinenbe: Maybe I take the scrolling approach, then I have some use for the scrolling routines I built into the framwork... 01.03.33 # *framework 01.04.57 # I just will have to make sure that the cursor never reaches the display border unless it is also the playfield border. 01.21.48 # hardeep, got that fix out yet? 01.24.40 # hah @ mini ipod sound problems, poorly enginered headphone jack may lead to static and crackling after 35-40 days 01.25.09 # haha! 01.25.27 # apple cant even make a headphone jack right... 01.25.30 # I did the same thing with my maze game 01.25.33 Nick BC|NeedsFood is now known as BC (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 01.26.40 # BC: Should I know it? Didn't see that anywhere... 01.26.52 # apple didn't make the jack dipshit 01.27.36 # apple fanboy alert 01.27.37 # off for a small bit 01.27.40 # heh no 01.27.42 # I am still waiting for the win32sim to work before I try to finish it 01.27.50 # still wanna go first person too 01.27.52 # just don't enjoy ppl hating apple for the wrong reasons 01.28.42 # BC: Will your maze game feature grayscale? 01.28.53 # LOL - It will now :) 01.29.19 # So you cannot test it on the sim, even the sim would be working. 01.29.33 # *if the sim would be working. 01.30.04 Quit midk () 01.30.08 # When the sim is working, maybe I will patch it up to support greyscale?? 01.30.22 # not like a PC cannot emulate greyscale :) 01.30.29 Quit hardeep (Read error: 104 (Connection reset by peer)) 01.31.14 # Sure a PC should be able to show grayscale, it's just the way grayscale is working on the target: it uses a timer interrupt. 01.31.17 # either way, the graphics need to be beta's on a real unit - but a real unit is a pain to dev on 01.32.07 # i dont think it would be worth bothering to emulate to interrupt level - so long as the result looks smilliar, that should be good enough 01.33.25 # amiconn, there is thatrockbox video player for computers, so maybe code could be borrowed from that to make grayscae on the sim? 01.33.32 # There are no api functions for grayscale that could be emulated (yet): my grayscale code is banging the hardware to set the timer interrupt. 01.34.05 # YOUR greyscale code - didn't realise - well done dude :) 01.34.22 # I will be running your demo just as soon as my jbr has a charge 01.34.51 # at some point it does a "plot" in some manner - that'll be the point to catch it 01.35.02 # Well, the idea (using a timer to flip between several bitmaps) is from [IDC]Dragon's video plugin, but the framework is written by me. 01.35.12 # however, core changes are rarely accepted, so perhaps best I don't use it 01.35.33 # aha - how many z buffers? 01.36.06 # I was thinking about writing a games dev kit - z buffers would be handy 01.36.37 # z buffers? 01.36.43 # frame buffers? 01.36.54 # (showing my age) 01.37.35 # well, you can have anything from 1 to 32 bitmaps (yielding 2 to 33 shades of gray). 1 bitmap isn't that useful though. 01.37.59 # freeeeeeeeeeoooowwwwwwwwwww 01.38.38 # It does "graceful degradation": if the memory you supply to it isn't enough to store the requested number of bitmaps, it automatically uses fewer bitmaps. 01.40.09 # interesting 01.40.40 # so if I give enuf memory for 20 bitplanes i may still have 30 shades? 01.40.56 # hmm, suppose it's not a "bitplane" really 01.41.12 # (must look at code before settling on nomenclature) 01.42.29 # No, but if you request 32 bitplanes but only 20 of them fit into the memory you give it, then it allocates 20 bitmaps - you get only 21 shades then, but it still works. 01.43.10 # hmmm, does it tell me how many shades I have? 01.43.27 # (kettle) brb 01.43.38 # Yes - this is the return value of gray_get_buffer() 01.45.31 # You don't need to know this value for your code to work, since you set the brightness (of a pixel, line, whatever) with values from 0 to 255 regardless of the number of existing shades. 01.45.58 # ooh, well done :) 01.46.11 # although maybe 0..255 is overkill? 01.47.05 # makes "shade++" impossible 01.47.29 # I though this is the easiest solution since it allows to take arbitrary grayscale bitmaps (e.g. in a picture viewer) and hand it over. 01.47.43 # fair call 01.48.32 # maybe a "scale mode" switch on it? 01.48.37 *** Saving seen data "./dancer.seen" 01.49.40 # Hmm, should be possible, but would add quite some complexity. 01.50.00 # hmm, maybe costly option in an interrupt 01.51.04 # All these calculations are done outside the interrupt. The interrupt routine only copies the next bitplane to the LCD every time it is called. 01.51.33 # phew 01.52.41 # first thing should be to write a 64x64 id3 image viewer 01.53.01 # The problem would be the speed: the core routines are heavily optimized (the pixel setting is now written completely in assembler), but it still takes ~1 s to set a full-screen grayscale overlay with 32 bitplanes to a specific shade when then interrupt is running. 01.53.23 # OW! 01.53.52 # It will be faster if (1) you use fewer shades, (2) if you use a partial overlay 01.54.28 # It will also render faster while the interrupt is not running 01.54.43 # anyone say "FAST" mode - LOL 01.54.58 # (if you remember the ZX81 (US=TSR80)) 01.55.17 # I know that, as well as the ZX Spectrum. 01.55.32 # "FAST" disabled the screen refresh 01.56.22 # So if I do "clear_to_grey(20); clear_to_grey(10);" ...that would take about 2 seconds to complete? 01.56.45 # The problem is that every "gray" pixel corresponds to one bit in each of the bitplanes, so setting a pixel involves a lot of bit shifting and masking. 01.56.55 # hmmmm 01.57.03 # how have you oriented the screen? 01.57.09 # on the X or Y axis? 01.58.04 # The screen data is oriented the same way as the internal LCD layout, all other layouts would be impossible to handle within the interrupt (way too slow). 01.58.26 # so 1 byte does a single X and 8 Y's? 01.58.52 # scuse me, i've not dug too deep in that bit before 01.59.02 # Yes, but there is one byte for a single X and 8 Y's _in each bitplane_. 01.59.31 # understood just trying to understand it all so I can think ahead 02.00.21 # Even this layout takes ~50% CPU power for full-screen solely for the interrupt.. 02.01.33 # can i have a greyscale window? 02.02.03 # does cpu useage go down with bitplane count? 02.02.10 # Yes, the grayscale framework works like an overlay. See my comments within the source. 02.02.31 # yes, sorry, i glimpsed the source, but should read it properly 02.02.37 # CPU usage varies only with overlay size, not with bitplane count. 02.02.48 # okay 02.02.54 # seems weird 02.03.13 # sure if there were only 16 bitplanes then the interrupt could do_nothing() 50% of the time 02.03.19 # surely... 02.04.16 # It is in no way weird. I told you that the interrupt routine only copies the next bitplane over to the LCD every time it is called. If it reaches the last bitplane, it starts over in the next call. 02.04.43 # how often does the interrupt fire? 02.04.54 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 02.05.32 # The repeat frequency is choses to approximate the internal scan rate of the LCD controller to minimize flicker. It is set to 67 Hz currently. 02.05.38 # *chosen 02.06.12 # I wonder if a less frequent update would help CPU overhead? 02.06.48 # Yes it would, but then you wouldn't get smooth grayscale, only flickering grains. 02.07.29 # surely 33.5 (if you get my drift) FPS would be beyond the human eye to detect? 02.08.07 # (hope you don't mind me chatting about this) 02.08.35 # No, because the total repeat frequency is 67 Hz / . 02.09.36 # 02.09.57 # Even with the current parameters the gray areas look a bit "grainy" when using 32 bitplanes. 02.10.34 # yes, I think I am getting it - just installing the demo now 02.10.41 # does it work with 2.2 native? 02.10.50 # This is more noticeable if the display is warm, because the LCD is faster then. 02.11.16 # Should work with 2.2 since it does not use esoteric new features. 02.11.57 # "esoteric" ...love that word :) 02.14.29 # very nice :) 02.14.43 # but it IS slow...hmmm 02.15.06 # some carful though will need to be given to screen updates 02.15.51 # Tried using the "cursor" buttons? 02.16.00 # yes, they're VERY smooth :) 02.16.19 # loses data that goes off the screen tho - guess that's just implementation 02.16.52 # Yes, it is scrolling, not rolling. 02.17.21 # need to rethink my ideas tho 02.17.48 # scrolling l/r can be done by any pixel amount with the same speed, scrolling u/d by 1 pixel (slow) and by 8 pixels (significantly faster; not shown in the demo) 02.18.06 # fer sure 02.18.23 # If you hold l/r in the demo, it scrolls by 3 pixels. 02.18.37 # right, yes I did 02.18.42 # that makes sense 02.20.07 # The usage differs from the b & w api functions in a way that there is no dedicated update() function. 02.20.48 # Every graphics primitive you call writes to the various bitplanes, the interrupt does "automate" the update. 02.20.49 # I find update() quite annoying anyway, so that's no bad thing 02.21.02 # cool 02.21.11 # i need to get busy on that poker game iwas goign to make... 02.21.44 # AI? 02.21.45 # The fastest graphics primitive (for larger screenn areas) is inverting a rectangle. 02.22.14 # BC, you mean for the poker game? 02.22.26 # diddy: yes 02.22.55 # BC: yes maybe, but i will most likly start with a simple "get as many points as you can" version 02.23.42 # i was thinking about making the cards in grayscale, but i haven't looked at the framework yet to see how hard that would be 02.25.26 # ami: in first person the whole screen updates every time - so i guess that's out of the question? 02.25.27 # diddystar5: shouldn't be that hard if you read the comments in it - usage doesn't differ that much from the api functions for b & w. 02.25.46 # gray_drawgraymap 02.25.54 # amiconn, ok, i will look at it now, and get started on making the graphics 02.26.17 # BC: "first person" ? 02.26.26 # doom 02.26.30 # (for example) 02.26.49 # Ah ok. Guess this would be too slow. 02.27.13 # can I demand X bitplanes? 02.27.58 # Yes, you can: int gray_init_buffer(unsigned char *gbuf, int gbuf_size, int width, int bheight, int depth); 02.28.08 # i have a doom game written in assembly for my ti83+ 02.28.31 # porting asm in an arse! 02.28.36 # in->is 02.28.43 # the graphics in it are awsome (for a calcultor) 02.28.59 # so the update will be quicker if I deman only 8 bitplanes ....hmmm 02.30.58 # what should be the resolution for the spade (or any suite) bitmap? i'm bad at guessing maybe 8x8? 02.31.54 # diddystar5: You can use any size that looks good and fits in the display. There are no speed advantages in choosing powers of 2. 02.32.16 # amiconn, ok, i will go with 12x12 to start 02.32.30 # YOU NEED 7X7 FOR A SPADE 02.32.33 # sorry for shouting 02.32.44 # +1 pixel space all around it 02.32.48 # ==9x9 02.33.01 # or maybe only one pixel above and to the left = 8x8 02.33.14 # ? 02.34.03 # you ...that means not me 02.34.04 # need ...as in what is required 02.34.04 # lol 02.34.16 # umm ok lol 02.34.20 # BC: The speed of the rendering depends linearly on the width, height and number of bitplanes. However, you will gain more speed from using a smaller screen area, since the the interrupt "steals" less CPU time. 02.34.21 # gimme a clue on where you got lost? 02.34.51 # why 8x8? 02.34.56 Quit Ka_ ("* poof *") 02.35.08 # ami: yes, thinking of how to get back time for the 3d calculations 02.35.25 Nick c0utta is now known as c0utta{afk} (~c0utta@200.cust47.nsw.dsl.ozemail.com.au) 02.35.45 # diddy: maybe just 7x7, but all your grphics will be butted right up to each other 02.35.57 # BC: You really want to give *3D* a try? WOW! 02.36.11 # it's not that hard really 02.36.27 # I'm just wondering if we have the power to do it in grey 02.36.56 # al the maze algorithms etc are already written 02.37.42 # A possible way to speed up the grayscale rendering significantly (already suggested by [IDC]Dragon) would be to place it into IRAM. 02.38.01 # i'm working on a variation on the bressenhams to produce a fast bitmapping algorithm 02.38.12 # This would require it to be in the core, though. 02.38.19 # yes, read about that - didn't really understand it 02.38.44 # not sure what the IRAM is -didn't look it up 02.39.15 # The SH1 has an internal ram which it can access without RAS/CAS delays and with 32bit width - this is the IRAM. 02.39.33 # righty - L1 RAM :) 02.39.44 # makes sense 02.39.56 # Unfortunately it is rather small (only 4096 bytes) and only usable from within the main firmware. 02.40.30 # It would give around 60% speedup (from my calculations - not tested that) 02.40.37 # shit! 02.40.40 # WOW! 02.40.40 # geeze its hard to put a spade in a 7x7 spot 02.40.50 Join Ka_ [0] (~tkirk@pcp261336pcs.howard01.md.comcast.net) 02.41.01 # diddystar5: I suggest 02.41.06 # ooops 02.41.37 # ---x---, --xxx--, -x-x-x-, xxx-xxx, -x-x-x-, ---x---, --xxx-- 02.42.12 # diddystar5: Please bear in mind that the pixels on the LCD aren't square - they are taller than wide. 02.42.26 # will look even better then :) 02.42.43 # one sec... 02.43.20 # Another suggestion: If you use a real grayscale bitmap, you can do anti-aliasing. 02.43.26 # fwiw - they were sent to me by a friend who write games for nokia ;) 02.45.03 # BC, didnt turn out nice, but one sec, i think i cna make it nice 02.51.35 # sorry :( it all looked cool on the test screen he sent me :( 02.53.39 Quit AciD ("indent -kr -nbad -bap -nbbb -nsc -br -nce -cdw -ss -cli2 -npcs -ncs -i6 -ts6 -saf -sai -saw -di0 -nbc -npsl -brs -lp -ip6 -pp) 02.55.50 # ---x--- --xxx-- --xxx-- xxxxxxx xxxxxxx ---x--- 02.55.53 # Perhaps I will try to put the grayscale pixel routine into IRAM to get real-world speedup figures. Then we'll have to convince the core developers that we need grayscale in the main core to get BC's super-duper 3D game running. 02.55.55 # thats the best i could do 02.56.33 # diddy: that's 7x6 02.56.44 # actually, on line 4, -xxxxx- ooks better 02.57.01 # ami: well, don't rest it on me, the game is unlikely to undergo any more dev until the sims are working again 02.57.14 # whoops, make a copy of line 2 as 3 02.57.17 # thats what it was 02.57.36 # diddy: yes that makes sense 02.59.53 # the diamond was easy :) 03.00.01 # ami: still need to get around the frame redraw tho ...hmmm 03.00.05 # lol 03.01.39 # a heart is a diamond with bobbles on the top 03.01.55 # haha yay, i just finished the heart now 03.02.12 # a spade is the top half of a diamond with the bottom half of a club 03.02.14 # now for the hardest one.... 03.02.53 # i also found some source to the linux poker game, so i dont have to work out all the logic 03.03.15 # cheat 03.03.19 # lol 03.03.38 Join midk [0] (mk@ACA29BF3.ipt.aol.com) 03.03.48 # think I might have to nasty ways to cheat on the 3d maths 03.04.10 # yo all. 03.05.02 # hey the club wasnt all that hard 03.05.18 # LOL 03.05.24 # that's what I sent you!? 03.05.45 # it was? well it didnt look like one lol 03.05.58 # now a set of numbers... 03.06.12 # yep 03.06.16 # i have drawsprite routines to help print all this stuff on the screen 03.06.26 # in fact I have a set of numbers done already 03.06.35 # for the new audio screen 03.06.35 # cool 03.06.43 # use them :) 03.06.46 # could you send them? 03.06.47 # if you like 03.06.48 # BC: You will have to use integer maths to get it reasonably fast. If you want it even faster, you can use 16bit precision, but this requires assember (I do this in my pixel routines). 03.06.52 # they're on sourceforge 03.07.07 # BC: in your audio patch? 03.07.15 # ami: yes, int's all the way 03.07.55 # if I limit the animation step sizes I can strip the tables down to virtually nothing 03.08.17 # The bad thing when using C multiplication / division is that it uses subroutine calls. 03.08.30 # thinking maybe 15^ rotational steps 03.08.34 # OUCH! 03.08.46 # animation? 03.08.47 # what 03.08.50 # d i miss 03.09.09 # bc rolling a fag 03.09.43 # dids 03.09.45 #