Beta-test for several TICT programs...

RSS
Email

0 Kudos

Author	Comment
Lionel Debroux	Beta-test for several TICT programs...	Lead	[-]
Posts: 3079 (2005-06-08 15:36:09) Former Admin Reply Quote More My Recent Posts	After the ezboard breakin, I thought I'd better make a new topic... I've uploaded a number of things to the TICT FTP. Could you please test them and report here whether they work / whether you're happy with them ? TIA. * tict.ticalc.org/downloads/gray.s : optimized version of the TIGCCLIB grayscale routine. It is 40 bytes smaller than the current TIGCCLIB one, without trading VTI compatibility or different memory allocation schemes between HW1 and HW2-HW3. To use, just add the file to your TIGCC project (or make the equivalent transformation for command-line builds - compile to .o, add in the linking phase). Although it didn't crash VTI or TIEmu, I didn't test doublebuffering, for example. * tict.ticalc.org/downloads/ebkrdr209.zip : eBook Reader v 2.09. Several optimizations. * tict.ticalc.org/downloads...ss.tar.bz2 (also available in .zip form): TI-Chess 4.12. Be sure to test both faster and smaller executables. * tict.ticalc.org/downloads...0preb5.zip : fixes several bugs, most notably pixel macros; new functions (GraySingleSprite8, originally by Dave Randall).
Fisch2	TI-Chess	#1	[-]
Posts: 548 (2005-06-13 16:02:20) Reply Quote More My Recent Posts	TI-Chess v4.12 (both fast and small) worked fine for me. Saving/Loading, the main gameplay, different options, and the computer whooping my butt all seem to work okay still There's only a 2,199 byte difference between the two, so I'd recommend the fast/larger version. I'll get to the other tests when I have time.
Lionel Debroux	Re: TI-Chess	#2	[-]
Posts: 3079 (2005-06-14 07:07:52) Former Admin Reply Quote More My Recent Posts	Thanks a lot.
Fisch2	extgraph beta 5	#3	[-]
Posts: 548 (2005-06-15 17:16:50) Reply Quote More My Recent Posts	New Extgraph worked well with Sumo Wrestling and Excitebike 68k, but when I tried compiling Ice Hockey 68k, the new version crased on VTI. I traced it back to SpriteX8_OR_R(). When I replaced all calls to SpriteX8_OR_R() with SlowerSpriteX8_OR_R(), it worked fine. Is there possibly some incompatibility with (the new?) SpriteX8_OR_R() that would make it not work as it did in Extgraph beta 4? I started a bare test project to test out SpriteX8_OR_R() by itself and it worked fine. Other than that, all worked as expected.
Lionel Debroux	Re: extgraph beta 5	#4	[-]
Posts: 3079 (2005-06-16 07:20:31) Former Admin Reply Quote More My Recent Posts	Thanks for the report. I guess I messed up the X8 functions once more...
Fisch2	Re	#5	[-]
Posts: 548 (2005-06-16 15:40:36) Reply Quote More My Recent Posts	Don't be so sure. The bare test project worked fine with the X8_OR, though it could be just that it was so small that any possible corruption wasn't noticeable. Also, the other X8 functions used in Sumo Wrestling worked just fine (GraySpriteX8_MASK, GraySpriteX8_BLIT, SpriteX8_MIRROR_H_R, SpriteX8_MIRROR_V_R).
Lionel Debroux	Re: Re	#6	[-]
Posts: 3079 (2005-07-02 09:31:11) Former Admin Reply Quote More My Recent Posts	OK. Let's sum up the reports/requests I received: * something possibly wrong on ExtGraph X8 functions, as reported here. * fix a bug on GrayClipSprite32_MASK_R. * fix FastDrawLine(_R)(...,A_XOR); and FastLine_Invert_R: the two-ending draw process has trouble with the middle point in case the length of the line is odd. * add "FastTestLine" (partly done), "FastPixCollide", font support, GrayClipSpriteX8_X_R to ExtGraph. * finish the port of the second Grib demo to TIGCCLIB. * a Titanium-compatible TICT-Explorer. I hope I didn't forget any. [EDIT: updated the post]
Lionel Debroux	A modified grayscale routine...	#7	[-]
Posts: 3079 (2005-07-06 10:31:56) Former Admin Reply Quote More My Recent Posts	I uploaded a modified grayscale routine at tict.ticalc.org/downloads/gray.s The other version was integrated to TIGCC 0.96 Beta 5, but I left a copy of it: tict.ticalc.org/downloads/graydiffHW.s This version always (even on HW1) allocates both planes outside LCD_MEM. There are two main reasons to do so: I) the most limiting configuration in terms of usable memory is HW2/3 AMS 2.xx/3.xx, due to AMS 2.xx/3.xx having more internal variables and handles. It is also by far the most common one, as it has been the standard one since 2000, which is FIVE years ago. Therefore, ALL programs have to be designed for it. And, while it's true that using LCD_MEM for one plane on HW1 consumes significantly less memory - LCD_SIZE bytes - no program can rely on them being available, as they are merely not available on the most common configuration, HW2/AMS 2.xx. The memory the other approach does not use is effectively unusable, so why bother not using it ? It only makes the grayscale support more complicated and somewhat larger (26 bytes). II) the ExtGraph tilemap engine becomes directly usable without having to use Kevin's unsupported patches, whose calling convention wastes a4 (and therefore -mno-bss + global register variables in a4/ -freg-relative-a4, which are the most efficient way to access globals). a4 being outside of the standard calling convention ("can clobber d0-d2/a0-a1"), it is one of the few address registers permanently usable to store the pointers complex programs like tilemap engine clients use ! Could you please test it for me ? TIA.
Kevin Kofler	Re: A modified grayscale routine...	#8	[-]
Posts: 7071 (2005-07-06 13:09:34) Admin Reply Quote More My Recent Posts	*Quote:* This version always (even on HW1) allocates both planes outside LCD_MEM. This is a completely unsupported hack and will never be merged into TIGCCLIB. *Quote:* I) the most limiting configuration in terms of usable memory is HW2/3 AMS 2.xx/3.xx, due to AMS 2.xx/3.xx having more internal variables and handles. It is also by far the most common one, as it has been the standard one since 2000, which is FIVE years ago. Therefore, ALL programs have to be designed for it. But not only for it. *Quote:* And, while it's true that using LCD_MEM for one plane on HW1 consumes significantly less memory - LCD_SIZE bytes - no program can rely on them being available, as they are merely not available on the most common configuration, HW2/AMS 2.xx. The memory the other approach does not use is effectively unusable, so why bother not using it ? Because the user might want to store files and/or TSRs in the additional RAM! Why do programmers always assume their programs are all a user ever wants to put in his/her RAM??? *Quote:* II) the ExtGraph tilemap engine becomes directly usable without having to use Kevin's unsupported patches ... but using your unsupported gray.s hacks instead. *Quote:* whose calling convention wastes a4 (and therefore -mno-bss + global register variables in a4/ -freg-relative-a4, which are the most efficient way to access globals). a4 being outside of the standard calling convention ("can clobber d0-d2/a0-a1") , it is one of the few address registers permanently usable to store the pointers complex programs like tilemap engine clients use ! Technically, %a4 is already reserved for parameter passing in TIGCCLIB, see *scanf.
Lionel Debroux	Re: A modified grayscale routine...	#9	[-]
Posts: 3079 (2005-07-06 13:45:05) Former Admin Reply Quote More My Recent Posts	> > This version always (even on HW1) allocates both planes outside LCD_MEM. > This is a completely unsupported hack and will never be merged into TIGCCLIB. We all know that, I've stopped asking for it. That's a non-argument. Many things are not merged in TIGCCLIB, not supported by the TIGCC Team, but widely used, aren't they ? The "User wants to use TSRs" argument is somewhat bad: there are usually more TSRs on AMS 2.xx than on AMS 1.xx. For example, h220xTSR (although HW2/3Patch, which is more powerful, should be used instead at least for this reason) and Auto Alpha-Lock Off... > > II) the ExtGraph tilemap engine becomes directly usable without having to use Kevin's unsupported patches > ... but using your unsupported gray.s hacks instead. And ? They will work (provided I did not make a mistake commenting about six lines of code and moving two others...) and turn into better code ! Not to mention that my unsupported hack retains the calling convention, while yours breaks all modified functions. In general, I can't see how it being unsupported is a huge problem. TIGCC uses an _unsupported_ fork of GCC, doesn't it ? > Technically, %a4 is already reserved for parameter passing in TIGCCLIB, see *scanf. ... which hardly anybody uses, it's a fact, especially certainly no single tilemap engine client, so the argument is not valid here. IMO, you made a mistake using that register in TIGCCLIB. Using registers outside of d0-d2/a0-a1 can be more efficient, but it's up to the user to decide. I'm using a2 in the program I'm currently developing: not only the same parameter, a constant pointer, can be passed to multiple functions called consecutively, but also the same constant parameter is passed to subroutines. BTW, GCC messes up everything by saving/restoring the register and worse, needlessly using it instead of using a1. It seems that the GCC 4.0.1 prerelease is even worse than the GCC 4.0.0 release...
Kevin Kofler	Re: A modified grayscale routine...	#10	[-]
Posts: 7071 (2005-07-06 14:35:36) Admin Reply Quote More My Recent Posts	*Quote:* The "User wants to use TSRs" argument is somewhat bad: there are usually more TSRs on AMS 2.xx than on AMS 1.xx. Once again, you are deliberately mixing up HW and AMS. HW2 != AMS 2! There is both HW1 AMS 2 and HW2 AMS 1 (1.05). *Quote:* Auto Alpha-Lock Off Auto Alpha-Lock Off runs just fine on TI-89 HW1 AMS 2 (on my TI-89 HW1, for example). *Quote:* And ? They will work (provided I did not make a mistake commenting about six lines of code and moving two others...) and turn into better code ! Definitely not better in RAM consumption! *Quote:* Not to mention that my unsupported hack retains the calling convention, while yours breaks all modified functions. It doesn't "break" anything (I tested all 6 Tilemap Engine demos, they all work!), it just changes the calling convention.
Lionel Debroux	Re: A modified grayscale routine...	#11	[-]
Posts: 3079 (2005-07-06 14:44:44) Former Admin Reply Quote More My Recent Posts	> > The "User wants to use TSRs" argument is somewhat bad: there are usually more TSRs on AMS 2.xx than on AMS 1.xx. > Once again, you are deliberately mixing up HW and AMS. HW2 != AMS 2! There is both HW1 AMS 2 and HW2 AMS 1 (1.05). HW2 AMS 1.05 is extremely infrequent, which is why I'm always more or less deliberately ignoring it (and you're once again accusing me of doing so). OK, HW1 AMS 2 is not infrequent, and it has less RAM than HW1 AMS 1.xx, but it is still not the most common configuration. > > Auto Alpha-Lock Off > Auto Alpha-Lock Off runs just fine on TI-89 HW1 AMS 2 (on my TI-89 HW1, for example). ?? I didn't say anything else: there are usually more TSRs on AMS 2.xx than on AMS 1.xx. > > Not to mention that my unsupported hack retains the calling convention, while yours breaks all modified functions. > It doesn't "break" anything (I tested all 6 Tilemap Engine demos, they all work!), it just changes the calling convention. Stop nitpicking. I used the wrong word, but it remains that mine doesn't change the calling convention, while yours does.
Kevin Kofler	Re: A modified grayscale routine...	#12	[-]
Posts: 7071 (2005-07-06 15:06:55) Admin Reply Quote More My Recent Posts	*Quote:* OK, HW1 AMS 2 is not infrequent, and it has less RAM than HW1 AMS 1.xx, but it is still not the most common configuration. But much more common than the HW1 AMS 1 you keep talking about. *Quote:* > > Auto Alpha-Lock Off > Auto Alpha-Lock Off runs just fine on TI-89 HW1 AMS 2 (on my TI-89 HW1, for example). ?? I didn't say anything else: there are usually more TSRs on AMS 2.xx than on AMS 1.xx. But this is irrelevant, HW1 is what's relevant to the issue. *Quote:* > > Not to mention that my unsupported hack retains the calling convention, while yours breaks all modified functions. > It doesn't "break" anything (I tested all 6 Tilemap Engine demos, they all work!), it just changes the calling convention. Stop nitpicking. I used the wrong word, but it remains that mine doesn't change the calling convention, while yours does. But this is not any sort of problem!
Lionel Debroux	Re: A modified grayscale routine...	#13	[-]
Posts: 3079 (2005-07-06 15:16:51) Former Admin Reply Quote More My Recent Posts	> > > > Not to mention that my unsupported hack retains the calling convention, while yours breaks all modified functions. > > > It doesn't "break" anything (I tested all 6 Tilemap Engine demos, they all work!), it just changes the calling convention. > > Stop nitpicking. I used the wrong word, but it remains that mine doesn't change the calling convention, while yours does. > But this is not any sort of problem ! What if improvements are made to the tilemap engine and you are not maintaining the patch (I know this is unlikely and that you intend to remain in the TI-68k calculator communities for a long time, but... one never knows) ? Those who use your unsupported hack will be screwed up between an old version and its unsupported (and bad) calling convention, and a new version with the usual calling convention. Both support doublebuffering (for the latter, the users just have to use a routine whose memory layout is that of all grayscale supports but that of TIGCCLIB).
Kevin Kofler	Re: A modified grayscale routine...	#14	[-]
Posts: 7071 (2005-07-06 16:00:23) Admin Reply Quote More My Recent Posts	*Quote:* What if improvements are made to the tilemap engine and you are not maintaining the patch (I know this is unlikely and that you intend to remain in the TI-68k calculator communities for a long time, but... one never knows) ? 1. What does this have to do with the calling convention (i.e. the text you quoted)? 2. One of that "What if" nonsense. I do plan to keep maintaining my patch. What if you don't maintain your fork of Sasume's code anymore? What if Sasume stops maintaining the Tilemap Engine altogether? There's more to worry about than just me stopping to maintain my patched version. 3. If you worry about the future maintainance of my patch, why don't you maintain it? 4. What if you stop maintaining your unsupported hack to the TIGCCLIB grayscale routine? gray.s will probably get updates at some point, if nothing else then to support new hardware versions. Then the same applies when people use your corrupted gray.s.
Lionel Debroux	Re: A modified grayscale routine...	#15	[-]
Posts: 3079 (2005-07-06 16:12:07) Former Admin Reply Quote More My Recent Posts	Fine, I trapped myself. Posting it, I knew this also applied to me, and you couldn't do without posting this kind of things... From now on in this topic, if you don't get more constructive than you've been (several valid points, but more invalid arguments and nitpicking), I'll have you moderated. Let's get back on topic. Over and out, no complain allowed.
Kevin Kofler	Re: A modified grayscale routine...	#16	[-]
Posts: 7071 (2005-07-06 18:47:35) Admin Reply Quote More My Recent Posts	*Quote:* From now on in this topic, if you don't get more constructive than you've been (several valid points, but more invalid arguments and nitpicking), I'll have you moderated. You know you can't win, so you threaten me...
Lionel Debroux	Re: A modified grayscale routine...	#17	[-]
Posts: 3079 (2005-07-07 07:41:40) Former Admin Reply Quote More My Recent Posts	OK. Then let me talk about something I missed yesterday (and of course, you didn't bother to tell about them - as often, you argue nothing, but you're good at posting wrong or irrelevant things in topics which contain things you don't like). If I don't maintain my unsupported modifications of the grayscale routines, and there is a huge hardware change, then users can always fall back to the TIGCCLIB one, as the API is the same (and you won't change it for COMPATIBLITY issues). If I modify the tilemap engine calling convention, and you don't maintain your patch (no matter you want to maintain it, as I already told you, any of us can stop maintaining anything anytime - that is, any of us can die anytime), users will be trapped, unless they maintain the patch themselves. If I were as unconstructive in your own topics as you are here, you'd undoubtedly have already threatened or even moderated me ! So, let's try for once be as kind with you and your own software as you're often with me and the software I'm maintaining (despite the huge size/performance improvements - yes, I added bugs, but I'm sure you too would add bugs to your software, most of which is nowhere as complex as TI-Chess is, in case you started optimizing it...), and test your reaction: * your TI-BASIC as a scripting language, while technically non-uninteresting, is crap because it is BASIC and therefore slow; * your Backgammon is not an extremely complex piece of software. You did never make a real game. Your Backgammon is one of the very few programs using the technically non-uninteresting but nearly useless 3 plane support which eats up significantly more CPU power than the two plane one. There are hardly any graphical routines for the 3 plane support mode, and anyway, it flickers too much for many users to bear it. * your unsupported GCC hack somehow broke all four TICT programs I tested it on (an impressive score no previous version ever reached...), especially ebook (which "just" crashed the calculator). Your confidence that it worked was based on very shallow and inappropriate tests: you basically let crap go in the wild. * the TIEmu-TIGCC-debugging branch of TIEmu is slower than the original one, which is already unbearably / quite slow for < 1 GHz computers. Not to mention that while the toolchain works for several programs, it doesn't work for the only program I tested it with (TIEmu is closed by Windows for doing incorrect operations)... I have to test again with GCC 4.0.1, though. See how stupid this is and where that leads ? Open your eyes: that's what you are doing once more here. With that, wonder why I said I'd have you moderated, with a notice that no complaints were allowed (notice that I didn't have you moderated, nor I won't...). Note that the entire discussion is mirrored on my HD, to keep it as a reference of who you actually are (too few people know who you actually are, unfortunately). [EDIT by Lionel: modified the text] [New EDIT by Lionel: had forgotten about TIEmu-TIGCC-debugging...]
Kevin Kofler	Re: A modified grayscale routine...	#18	[-]
Posts: 7071 (2005-07-07 16:01:30) Admin Reply Quote More My Recent Posts	*Quote:* If I don't maintain my unsupported modifications of the grayscale routines, and there is a huge hardware change, then users can always fall back to the TIGCCLIB one, as the API is the same (and you won't change it for COMPATIBLITY issues). But they'll have to switch to the patched version of the Tilemap Engine in that case! *Quote:* If I modify the tilemap engine calling convention, and you don't maintain your patch (no matter you want to maintain it, as I already told you, any of us can stop maintaining anything anytime - that is, any of us can die anytime), users will be trapped, unless they maintain the patch themselves. Well, see above, the alternative also requires them to switch their Tilemap Engine version if they switch. We already went through a Tilemap Engine API change, it wasn't that hard for me to update my patch. Any competent person should be able to do it, if something really bad should happen to me. And I heavily dislike your and Sasume's way to constantly break the Tilemap Engine API. Don't you ever think about compatibility? An API is something which should not change. Otherwise, people will have an easier time working with an old patched version than with a recent unpatched version *Quote:* So, let's try for once be as kind with you and your own software as you're often with me and the software I'm maintaining Wow, huge pileloads of off-topic trolls... *Quote:* * your TI-BASIC as a scripting language, while technically non-uninteresting, is crap because it is BASIC and therefore slow; The point of scripting languages is to be easy to program, not to be fast. That's why they are scripting languages and not programming languages. *Quote:* * your Backgammon is not an extremely complex piece of software. You did never make a real game. Backgammon is a real game. I never claimed it to be as technically advanced as Thomas Nussbaumer's TI-Chess is (and yes, I put Thomas' name there on purpose, because he's the one who did all the work, not you). *Quote:* Your Backgammon is one of the very few programs using the technically non-uninteresting but nearly useless 3 plane support which eats up significantly more CPU power than the two plane one. 3 plane grayscales mean more shades of gray than 2 plane grayscales, so they are hardly useless. And they don't eat any more CPU power than 2 plane grayscales! The plane switches happen at the same speed because the LCD won't allow anything faster. That's also why the exposition times are longer and the flickering is higher. *Quote:* There are hardly any graphical routines for the 3 plane support mode Then why don't you write them for ExtGraph? I only needed one sprite routine, so I wrote that one (and my sprite routine is actually more powerful than what I actually need, it's clipped and I never overdraw the screen in Backgammon; but better safe than sorry, IMHO all sprite routines should be clipped). *Quote:* and anyway, it flickers too much for many users to bear it. I never received a complaint about the flickering for Backgammon, at least not from someone actually interested in playing the game. *Quote:* * your unsupported GCC hack somehow broke all four TICT programs I tested it on (an impressive score no previous version ever reached...), especially ebook (which "just" crashed the calculator). Your confidence that it worked was based on very shallow and inappropriate tests: you basically let crap go in the wild. I let a version out for testing (and it was explicitly labeled as such). Nobody can test software better than the users! But it also had plenty of improvements over the old GCC 3.3.3, and it worked fine for me, so I recommended users to try it out on their programs (but I also told them to keep the old version around in case of any problems). Moreover, any problems they encountered were usually fixed within 48 hours, generally even within 24 hours. So I don't see how that's a problem. *Quote:* * the TIEmu-TIGCC-debugging branch of TIEmu is slower than the original one, which is already unbearably / quite slow for < 1 GHz computers. It is not slower for non-debugging use except when loading the ROM (as it also has to initialize Insight). For debugging use, the features are well worth the slight slowdown. It works fine on my PIII 733. *Quote:* Not to mention that while the toolchain works for several programs, it doesn't work for the only program I tested it with (TIEmu is closed by Windows for doing incorrect operations)... Did you compile the project under Windows as well? You can't compile a project under Linux and debug it under Windows or the other way round, you have to use the same OS for compiling and debugging. And the program it failed on is LGC, right? Or am I mixing up things? (Sorry, I was pretty busy these days, so I wasn't able to test this earlier.)
Lionel Debroux	Re: A modified grayscale routine...	#19	[-]
Posts: 3079 (2005-07-07 16:31:57) Former Admin Reply Quote More My Recent Posts	I intentionally added a number of trolls which are not necessarily true, to try to make you understand what you keep on doing. About users having to switch to the patched version of the Tilemap Engine in case the other grayscale routine is not maintained (which is impossible): well, I didn't think of it. As you say updating your patches is easy, I guess we're going to stick to the current situation: official tilemap engine / unofficial grayscale routine, unofficial tilemap engine / official grayscale routine... > > your Backgammon is not an extremely complex piece of software. You did never make a real game. > Backgammon is a real game. A board game, yes. The AI is mostly the only complex part of it. It's not quite the same thing as games with lots of graphical stuff and a more advanced gameplay (Ice Hockey 68k, Duke68k, many other ones), is it. > I never claimed it to be as technically advanced as Thomas Nussbaumer's TI-Chess is I know that. Maybe my post let believe so ? > (and yes, I put Thomas' name there on purpose, because he's the one who did all the work, not you). Why do you think I did not add myself in the "About menu" of TI-Chess ? But "all" is unfair, as the optimization is mine, not his. Remember that if using the "smaller" version, TI-Chess is now 10 KB smaller (compressed, I don't know the exact value for uncompressed size, but it is probably at least as much) than it used to be when I took it over. > And they [3 plane grayscales] don't eat any more CPU power than 2 plane grayscales! The plane switching mechanism itself, yes. But having 3 planes instead of two basically means you have 50% more work to do (and +50% is significant !) when drawing things. > > There are hardly any graphical routines for the 3 plane support mode > Then why don't you write them for ExtGraph? Because like many, I find this mode mostly useless (if you want more than 4 shades of gray, this is the wrong platform: switch to HP-49(G+) or old PDAs), and the performance penalty. Who is going to spend days writing all library functions for a mode hardly anybody uses (I know there's a Voxel demo out at ticalc - it would be less slow if using only 4 shades) ? > I let a version out for testing (and it was explicitly labeled as such). Nobody can test software better than the users! And ? Your tests were too shallow, that's all. It's obvious that users can test software better than you can (all the more since you do not make proper tests !). I did not use Linux to compile or debug anything. > And the program it failed on is LGC, right ? Right.
Kevin Kofler	Re: A modified grayscale routine...	#20	[-]
Posts: 7071 (2005-07-07 16:47:22) Admin Reply Quote More My Recent Posts	*Quote:* > I let a version out for testing (and it was explicitly labeled as such). Nobody can test software better than the users! And ? Your tests were too shallow, that's all. No, they were never intended to be complete, that's what users are for! Who do you think is testing Rawhide (the Fedora development branch)? ... *Quote:* It's obvious that users can test software better than you can (all the more since you do not make proper tests !). It's the other way round: I didn't test it more than that because I knew the users would.

<< Previous Topic Next Topic >>

Yuku free message boards

Beta-test for several TICT programs...

Beta-test for several TICT programs...