Re: A83: libraries (no offense intended to Phelan or Joe here)

[Prev][Next][Index][Thread]

Re: A83: libraries (no offense intended to Phelan or Joe here)


The point I am trying to make is that it would be easy to do, so all the
idiots at school who have TI-83s just because they stole them and want to
play games can transfer the games also.  Thus creating a larger user base.
Wouldn't you rather have everyone who has a calc playing your game rather
than everyone who knows how to transfer a program playing your game?

-Miles Raymond

-----Original Message-----
From: Dan Englender <jfsmi@geocities.com>
To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
Date: Friday, October 02, 1998 7:18 PM
Subject: Re: A83: libraries (no offense intended to Phelan or Joe here)


>
>Hehe, but you're not really playing tetris with optimal ram free.  Optimal
>ram free would be not having the code to send inside the shell, saving lots
>of space, and just sending over the libs needed by tetris (yes I know, its
>very hard work to send libs over manually ;)
>
>-Dan
>-----Original Message-----
>From: Miles Raymond <m_rayman@bigfoot.com>
>To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
>Date: Friday, October 02, 1998 8:10 PM
>Subject: Re: A83: libraries (no offense intended to Phelan or Joe here)
>
>
>>
>>The idea of controling link functions inside the shell is so that only the
>>necessary libs are sent to the recieving calc.  Say calc1 has tons of
>games.
>>Say calc2 has nothing.  Calc2 want tetris, and only tetris.  Calc1 sends
>>calc2 the shell.  When both calcs are in the shell, calc1 selects tetris
to
>>be sent over.  The shell on calc1 determines which libs tetris uses.
Calc1
>>sends tetris and ONLY THE NECESSARY libs over to calc2.  Calc2 can now
play
>>tetris with optimal RAM free.
>>
>>-Miles Raymond
>>
>>-----Original Message-----
>>From: Joe Wingbermuehle <joewing@usmo.com>
>>To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
>>Date: Friday, October 02, 1998 3:22 PM
>>Subject: Re: A83: libraries (no offense intended to Phelan or Joe here)
>>
>>
>>>
>>>hehe, I'd like to see the code to that too! The object of libraries is to
>>>save space, not make the shell so big that libraries don't help.
>>>Anyway, since I made ZLib my ideas about libraries have changed somewhat.
>>I
>>>think each library should only have a small number of large, related
>>>functions (like ZGFXL).  ZLib has some functions that I think I should
>take
>>>out, but I'm reluctant because I'm afraid it would make some games crash
>>>etc...
>>>The beep function is used in pretty many games, but the delete function
is
>>>not used at all that I know (please don't use the delete function if you
>>>think I should remove it from the next release...).
>>>
>>>btw, why do you need a shell to send files? The link stuff built in to
the
>>>calculator will send the files in the correct order since libraries begin
>>>with Z, you just have to be careful to send all the libraries--not that
>>it's
>>>the end of the world if somebody has to go a day not being able to play a
>>>particular game...
>>>
>>>Joe Wingbermuehle
>>>http://www.usmo.com/~joewing/
>>>
>>>-----Original Message-----
>>>From: Miles Raymond <m_rayman@bigfoot.com>
>>>To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
>>>Date: Friday, October 02, 1998 9:53 AM
>>>Subject: Re: A83: libraries (no offense intended to Phelan or Joe here)
>>>
>>>
>>>>
>>>>Me too.  I'd love to see the code for that.  Right now, I am just an
>>>>ideaman, and not a programmer.  I'm trying to learn, but it's hard when
I
>>>>don't have a GL to use.  And no, I don't know how complicated that would
>>>be,
>>>>but I get the idea from your message. =)
>>>>
>>>>-Miles Raymond
>>>>
>>>>-----Original Message-----
>>>>From: James Matthews <matthews@tkb.att.ne.jp>
>>>>To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
>>>>Date: Friday, October 02, 1998 7:36 AM
>>>>Subject: Re: A83: libraries (no offense intended to Phelan or Joe here)
>>>>
>>>>
>>>>>
>>>>>No offense to anyone here, but I'd LOVE to see the code for that.  Do
>you
>>>>have any idea how complicated that'd be :)
>>>>>
>>>>>Later,
>>>>>
>>>>>James Matthews (matthews@tkb.att.ne.jp)
>>>>>
>>>>>PS:  cool idea, though :)
>>>>>
>>>>>ICQ: 7413754
>>>>>http://home.att.ne.jp/gold/tomcat21/index.html
>>>>>http://library.advanced.org/18242/
>>>>>
>>>>>----------
>>>>>> From: Miles Raymond <m_rayman@bigfoot.com>
>>>>>> To: assembly-83@lists.ticalc.org
>>>>>> Subject: Re: A83: libraries (no offense intended to Phelan or Joe
>here)
>>>>>> Date: Friday, October 02, 1998 10:29 AM
>>>>>>
>>>>>>
>>>>>> What if someone made a shell that did file transfer, and in each
>>>program,
>>>>it
>>>>>> contained information on which functions in each library it used.
>That
>>>>way
>>>>>> the shell could determine which libraries to send to another calc.
>>>>>>
>>>>>> On the recieving end, the shell would check the libraries and make
>sure
>>>>it
>>>>>> had the same, if not later version of the library as the sending
calc.
>>>>If
>>>>>> the sending calc's library was older, then the shell either could ask
>>or
>>>>>> preferably, ignore the incoming library.
>>>>>>
>>>>>> Even better that that idea, is one where the two shells send each
>other
>>>>info
>>>>>> on their libraries.  The sending calc would then never transmit an
>>older
>>>>>> library.
>>>>>>
>>>>>> Both these ideas would make tansfering shell-specific programs a
snap.
>>>>>> Maybe this should be added to the next SOS?
>>>>>>
>>>>>> -Miles Raymond
>>>>>> -----Original Message-----
>>>>>> From: Alan C Johnson <benjamin99@juno.com>
>>>>>> To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
>>>>>> Date: Thursday, October 01, 1998 8:11 PM
>>>>>> Subject: Re: A83: libraries (no offense intended to Phelan or Joe
>here)
>>>>>>
>>>>>>
>>>>>> >
>>>>>> >The main problem with libraries, though, is that sometimes you have
>>>>>> >routines that aren't used by enough programs to make a memory
>>"profit".
>>>>>> >Take ZLIB for example (no offense Joe), just about every ZLIB game
>>uses
>>>>>> >ramdom, but there are routines that aren't commonly used by games,
>>such
>>>>>> >as 'beep'.  The point is, that every calc owner has different games.
>>>>>> >Depending on what games they have, they might only actualy need 1
>>>>>> >function out of a library, while the rest of the lib is a waste of
>>>>space.
>>>>>> > I'm ok with having ZLIB and ZGFXL on my calc, but i won't be ok if
>>100
>>>>>> >different libraries come out and each game needs a different on, or
>>>ZLIB
>>>>>> >grows past 1KB, because after that, you might as well just not have
>>the
>>>>>> >lib.  I reluctant to have ZINPT on my calc, but that's a different
>>>story
>>>>>> >because I don't think it was made well. This is a different story on
>a
>>>>>> >computer where while you have limited space, you can almost always
>>>>>> >expand.
>>>>>> >
>>>>>> > Thanks for listening,
>>>>>> > Alan
>>>>>> >
>>>>>> >
>>>>>> >>do dlls work like libraries on the calc.  If so why don't we set
>>>>>> >>standard dlls for everyprogram to use.  The would hold pixel,
>sprite,
>>>>>> >>
>>>>>> >>graphing, and many other commands.  This would be great to have so
>>>>>> >>that
>>>>>> >>games would be cut in half.  And if not, I'll make a shell and
>>convert
>>>>>> >>
>>>>>> >>every game to work with the dlls.  And like every new version of
>>VC++,
>>>>>> >>
>>>>>> >>new dlls would come out, overwriting the old.  And just like on
your
>>>>>> >>pc,
>>>>>> >>if one isn't present, or not updated enough, the program would say
>>>>>> >>so.
>>>>>> >>
>>>>>> >>-Phelan 'Amen' Wolf
>>>>>> >>______________________________________________________
>>>>>> >>Get Your Private, Free Email at http://www.hotmail.com
>>>>>> >
>>>>>> >___________________________________________________________________
>>>>>> >You don't need to buy Internet access to use free Internet e-mail.
>>>>>> >Get completely free e-mail from Juno at http://www.juno.com
>>>>>> >Or call Juno at (800) 654-JUNO [654-5866]