sschaem@starnet.uucp (Stephan Schaem) (03/25/91)
This is post only on the programer side and is a reply of the tutorial writen by Mike Farren. I really hope you have time to read the following.You might find that game programer are not all ignorant people like Mike Farren want us to beleive! After reading his 4 part Attack/leason on game programing I had to prove something... >(Mike Farren): >even more, I hope that game programmers will take a >hint or two - leave us our Amigas, please! Dont I feel a little pretention here.I dont like that, especially when you attack other people! especially my profesion. First a VERY few things I wanted to comment on your posting. -ROM CODE: Sure it was designed to make action games:-). It can be used for it but it's not made for it! Try to do intensive copper activity with the system function! Try to do anything the rom was not design for! -DISPLAY: Some game actually need steady frame rate. Ok, now that you got trought Lemings can you write the same sugestion with TurricanII or SW-IV or OVERDRIVE etc...? -MULTITASKING: Have you EVER monitored the system! Move your mouse around, moving the mouse take more than 20% of the CPU time! 1%? Why do you want to multitask if you use the CPU 1% on the other side! And puting the OS to sleep and waiking it UP is the closest you can get to it with this kind of game. Here also make TurricanII or XENONII or OVERDRIVE etc.. true multitasking. -DISK FORMAT: 980K? not 1035K? (why have they step down?) Right now you can get over 1.1 meg, but not with the system. And 1.7 meg with data crunching included in the driver ... So 880K VS 1.7 MEG! You can have 2.4 meg disk messing around with MFM clocks, not safe... Also Game like SW-IV or OVERDRIVE use the drive has virtual memory. So 512K user can have 1MEG quality games! -MEMORY: Dont you think some people apreciate to be able to buy software for their 512K machine!!! I hope so. -HD INSTALABLE: There is absolutly no barrier for that for any floppy games. Well only piracy. >BLABLABLA.... >I hope that these postings have been useful fuel for thought. I hope >even more that any fledgling game developers reading this will think, >the next time they do a game, about how simple it can be to have both >a good game and an Amiga-friendly game. You don't have to give up >much of anything, and you gain the respect and admiration of those who >like to use their computers to their fullest, while not losing the >respect of those who don't care. Well not everybody do simple games like you! People could ONLY take your advice seriously if you actually done serious coding and know whats involve.From what you write in your 4 letters I seen a LARGE lack of knowledge. Yes, Like the Bitmap Brother, the people at Rainbow Art, Inerprise etc etc.. dont know all about the stuff you are saying! Ok, what would you sugest to make my curent project 'more Amiga-friendly'? Maybe the following will tell you that other game programer KNOW what they are doing! and what is realistic. OVERDRIVE curently run from my HD, I can install it in memory (making it resident!) and play anytime I want without loading anything... So if I use DPaint III I just press a key to enter the game and onother key to return to DPaint. Even if the comercial version is only on disk and connot be resident, we are thinking of making the developer version available.Well if we survive that money pit! Games can be complex.We started a Ground Zero, with DevpacII, CED, DPIII, soundtracker and our life investment! nothing less, nothing more. NOTE: CED PRO and DevpacII are actually PERFECT Product.People at MICHTRON and especially CYGNUS can be respected! (we also have the backbone for a mutliprocessor compiler, for precessor type code convertion) For example that's what involved in OVERDRIVE: -A Duplicator driver for the Amiga ONLY, with function not found on ANY other profesional system.(We are thinking of making a commercial version). -A Disk languages was created for developing OVERDRIVE. The language have more than 80 instruction.like those: TYPE Specify the file type. Three types are available: EXTRAC, DI, CREATE and COMPACTOR. The first one allow you to extrac data from files. The second allow you to create a disk format. Each track can be created with it. (Each track should be... See TRACK instruction) Each type you want to use this disk write TYPE DISK "name". The third allow you to create a game disk. The forth take a soft disk created with GAME and write it on any units you want... You have to specify the disk name to be used. The fifth allow you to compact or convert some files. PICTURE (EXTRAC) This allow you to define picture decompactage. Four decompactage are available: NORMAL (Default) RAWBLIT SPRITE4 SPRITE16 HARDCOMP SIZE Allow you to save size at sta NOSIZE (Default) PIXEL X size written in pixel WPIXEL (Default) X size written in WordWidth*1 WORD X size written in word BYTESIZE Size written in a byte or wor WORDSIZE (Default) CTRL (Default) Save control word in sprite NOCTRL REMAP NOREMAP (Default) SYNC (DISK/GAME) Synchronisation is four hexadecimal number. In GAME mode: Define synchronisation to use for next file in GAME mode. Then it can be at any offset in track. In DISK mode: This define synchronisation of actual track. You can write SYNC+ to reach next track after you have define sync of this track. (Note: If end of disk is reached no track will be defined, and then you will need to use TRACK instruction again) This last way suppose you already define a track number. And it's very usefull when it's use at the end of a track definition! Note that the lways 0.5... ETC... So heres a little programe to extract a directory with IFF brushed: (of course the language is interactive). Type Extract Picture Size Picture RawBlit Depth 6 IffDir Picture Ram: -A Floppy disk driver for virtual memory. Sory Private information.But beleive me its good. -A Compacting algorithem. LZH is better... But I will get back to it! Including data type detection (using diferent algorithem for 8bit digit and text for example) -A Powerfull MAP Editor with literaly hundreds of functions. For example one of the selection screen of the editor has 53 functions for map manipulation and 35 for curent brush manipulation (GADGETS). All have key shortcut. Of course alot of gadget have sub window:like the filer option offer 7 other option. You can have an 'infinity' of brushes, with pattern fill with patterns. Multiple windows (having your ANYSIZE block screen next to your map, see multiple part of the map etc...) Of course you can do everything other editor do, save every single seting and configuration of the software. Of course everything file we read or write support iff. And Data manipulation are VERY powerfull. You have color manipualtion screen with mixing, sorting, remaping import/export etc... ColorCycling screen... Information screen.Where you can set the block info.Like level, type, Ttype, borders.(Let you modify system block info: superinfo, animation display type: rotation, xflip, yflip etc...) You can call an info screen and place it at the bottom to have a scall down of your screen/map with your location... And the editor can have multiple maps and block. AND alot more.... -A 290 functions library.Here is some of them...: We have resource tracking, error tracking, data check, structure check, debug function, function check etc... LIBINIT ;The CSD Console LIBDEF _OpenCSDConsole LIBDEF _CloseCSDConsole LIBDEF _CSDWrite LIBDEF _AnalyseString ........ LIBDEF _WOpen ;Open CSDWindow LIBDEF _WClose ;Close CSDWindow/Intuition LIBDEF _WaitW ;Wait For any Task window MSG LIBDEF _GetWMsg ;Message of this task Windows LIBDEF _ExecuteW ;Execute Message From Window The above handle 100% of the overhead for you, simple plug the structure! Of course you can KILL a CSD task with 100% of the resource restored. Analize string handle ansi text (not to mention). We also have another text control sequence for special display and calculation. We also document the function: ;---------------------------------------------------------------------------- CSDAllocMem NAME CSDAllocMem - Allocate memory for CSD usage SYNOPSIS MemBlk = CSDAllocMem(ByteSize, Requirements, StartPtr, EndPtr) SR/D0/A0 D0 D1 A0 A1 MemBlk = D1 FUNCTION This routine use ROM structure but don't go trough the Allocate function of ROM. This routine is made to "understand" largest flag bit. Also it's now easily possible to allocate the largest part of memory. But in this case you must always specify D0 like block size. (Also you will look for the largest block under D0 or with D0 size) Normaly if largest bit is set you will receive some memory... To have the largest possible block you will set D0 to null or -1. To end, D1 is returned with the size of allocated block. When FORCE and/or MEMABS bit are used A0 and A1 are needed to have a good allocation. A0 define the less start address of allocation and A1 the higher one. If MEMABS is specify also only A1 is usefull and define start address. (Like in ROM 1.x) At this time LARGEST bit and FORCE one couldn't be used at the same time. All the CSD memory allocations are linked togheter. Also if you forge to free all your allocated memories, CSD will do it for you. (NOTE: a requester will appear at the end when you will make the CloseLibra INPUTS ByteSize of memory to be allocated (Long word) Requiments - Defined type of memory (Largest allowed) PUBLIC All allowed memory for every tasks. CHIP Special processor memory. FAST 68000 memory only. CLEAR Return cleared memory. LARGEST Allocation of 8 bytes of memory to D0 bytes. FORCE Allocation of memory between A0 and A1 pointers. MEMABS Allocation of memory at address A1. RESULTS MemBlk - Pointer to the allocated memory (Already returned in A0) SR z - z is set correspondly to the result. If no allocation was done z will be zero, atherwise it will be set. SizeBlk - Return size of allocated block, this must be use to know block size after an allocate with the largest bit specification. If no allocation is done (With or not Largest bit) D1 will be null EXECPTIONS If length is null and largest bit is clear no memory is allocated. If length is null and largest bit is set the largest actual memory is allocated. Start and end addresses are reorder. Then you can send them in any or BUGS Don't return 0 in D1 when allocation is not done and largest bit is n (But return size...) SEE ALSO CSDAllocMemError() CSDFreeMem() CSDMemList() CSDTypeOfMem() ;---------------------------------------------------------------------------- AllocListSize NAME AllocListSize - Try to alloc memory and add it to a list SYNOPSIS Node = AllocListSize(List, ByteSize) D0 A0 D0 FUNCTION This function look for memory (Always cleared and public) and if memory was allocated, add it in a list and then the size is written in structure at the next position of "previous" pointer. Then you will be able to use this with FreeAllList() and a size of 0. A0 can be null if no list was already created. If not enough memory is present also no list will be adding. NOTE: the list is insert with InsertList routine (See). INPUTS List - List pointer (Null for none) ByteSize - Size in byte of the allocated list node (Note the size must contain the height byte of next and previous pointers of the beginning) RESULTS Node - Pointer to the added node EXCEPTIONS None NOTES A list of this type is formed with a Next pointer a Previous pointer and a word Size. Then you will be able to use the structure from the byte ten. BUGS None know SEE ALSO AllocList() AllocLargeList() CountList() CountEndList() FreeAllList() FreeEndList() FreeList() HeadList() InsertList() NextList() PreviousList() QueueList() RemoveList() SearchList() SearchNextList() All the our code are written in HIGHLY optimized assembly, Fully multitasking, Very structured.... We have pure code, READ only.Well We want to creat an operating system:-) And of course there is ALOT more than the above. 65xx, I remember doing a 1024 byte full text editor with disk support... But remember the 68000 is not a 6510, and graphics on 8bit machine is something else! MEMORY: ------- -DRAWINGS: Each level has more than 400 IMAGES of 16 pixel minimum and 50% in 16 colors and the rest full 64 colors! -MAPS: With 1024 Tiles of 16x16 in 64 colors for the map drawings.the map has big has 400 screens.Each block have control many words to tell the way they will be displayed, the way they are compacted, but colors blocks etc.. Those maps are 578K big with 160K of tiles: 738K already! -SOUND: 64K dedicated to sound and music. -SCREEN: 88K for the 64 colors half bright screens. -Each Fire (25 diferents) have buffer for up to 32 on screen. Fire have speed, aceleration, power, efect type, direction, animation... -OBJECT: You have to fill the 400 screens with something! you can get more than 100 moving object on screen... Each Object Have their own: SHADOWS Showing their height position. POWER For weapon protection and colision. WEAPON Type (see above), plus programed types. TRAJECTORY An internal interpreter, With the most used math function. ANIMATION Can be set by trajectory interpreter and many other ways. LINKAGE Object can be linked one another. EXPLOSION 5 type, up to 64x64 pixels. And alot more... We ave more than 80K of structure definition... ETC... I could write megs to explain the all game functions! OVERDRIVE use almost every bytes of those 512K! That's why its 3 months late now:-( Almost everything is compated during game play (not the sound or code). And if we knew that we could have made a 1meg version without loosing money 4 peoples wouldn't have developed for it for 1 1/2 years! We are STRONG AMIGA beleivers, and we get kicks writting ANYthings at least that it run on an AMIGA. Some of my good friends, like The creator of LightQuest and 5 others amiga games have to do PC, atari version too! He can program at the hardware level on 6 machine, but will get nothing by lEARNing the Amiga OS... See my point? DISK: ----- Actually I would say that the DOS we are using in OVERDRIVE is safer than AmigaDos!! So please... (Already talk about that, checksum done in read buffer). MULTITASKING: ------------- I also have a project started: a Multitasking game running a 60 frames second scroling in 32 colors.The scroll and interface work, so you could say that multitasking is possible... Its not an action game, so the system have enought time to run smothly.(A CLI scrolling and game scrolling work nice together.) CONCLUSION: ----------- Actually some people other than you know the Amiga.And if you want to tell them what to do, put them down, give them lessons you better check that the 'student' dont know more than the 'teacher'.... People dont make decision just like that! And if games dont multitask or are not HD installable dont mean that the developers are BRAIN DEAD and dont know the amiga! You text being published, that would hurt! Stephan Schaem. NOTE: Have you ever passed more than 15,000 hours on a single project?
rbabel@babylon.rmt.sub.org (Ralph Babel) (03/25/91)
In article <1991Mar24.204206.11145@starnet.uucp>, sschaem@starnet.uucp (Stephan Schaem) writes: > [Gartenzwergperspektive deleted] Move flames like these to comp.sys.amiga.advocacy or - better yet - to /dev/null. Thanks to Mike Farren for an excellent article! I hope you can sell it to a magazine. Ralph -- "Surprising what you can do when you use the OS ..." - Randell Jesup
rloon@praxis.cs.ruu.nl (Ronald van Loon) (03/25/91)
In <1991Mar24.204206.11145@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes:
[ interesting reply deleted ]
I hate to say this, but I have never seen an increasing left
margin before in my life, it doesn't really make things easier
to read and I can't believe Stephan has got a twenty character-wide
screen...
If
you
catch
my
drift...
--
Ronald van Loon (rloon@praxis.cs.ruu.nl)
There never seems to be enough time to do the things you want to do -
once you find them - Jimmy Croce "Time in a bottle"
--
Ronald van Loon (rloon@praxis.cs.ruu.nl)
There never seems to be enough time to do the things you want to do -
once you find them - Jimmy Croce "Time in a bottle"jesup@cbmvax.commodore.com (Randell Jesup) (03/26/91)
In article <1991Mar24.204206.11145@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: [ In a message formatted to make it darn near impossible to read... ] > I really hope you have time to read the following.You might find that > game > programer are not all ignorant people like Mike Farren want us to > beleive! Mike may be many things, but I wouldn't call him ignorant. > >(Mike Farren): > >even more, I hope that game programmers will take a > >hint or two - leave us our Amigas, please! > > Dont I feel a little pretention here.I dont like that, especially > when you attack other people! especially my profesion. Game programming is his profession also, and he's been at it longer (unless you're older than I think you are). > -DISPLAY: Some game actually need steady frame rate. Fine, take over the system then. You can still return gracefully on exit (or when paused). Also, by no means do all games need a perfectly steady frame - Lemmings doesn't have one now, for example. > -MULTITASKING: Have you EVER monitored the system! > Move your mouse around, moving the mouse take more than > 20% of the > CPU time! 1%? Why do you want to multitask if you use the > CPU 1% on > the other side! And puting the OS to sleep and waiking > it UP is the closest > you can get to it with this kind of game. Fine, so put it to sleep if you can't live with it. Restore it on pause or exit if possible. If there isn't enough memory to keep from killing it, let the user know, and if he wants to continue then take over completely. > -DISK FORMAT: 980K? not 1035K? (why have they step > down?) > Right now you can get over 1.1 meg, but > not with the system. And 1.7 meg with data > crunching included in the > driver ... So 880K VS 1.7 MEG! > You can have 2.4 meg disk messing around with MFM > clocks, not safe... > Also Game like SW-IV or OVERDRIVE use the drive > has virtual memory. > So 512K user can have 1MEG quality games! "Data crunching" (compression) has nothing to do with it, you can use that regardless of the disk format. I have not seen 1035K, and I don't believe it unless you violate the timing specs for the system and drive (as I published in an AmigaMail article and devcon article (low-level drive access). The basic spec is there are (with MFM) 6250 nominal bytes of data per track. Combine that with the amiga nominal timing (2.3% fast), disk speed slop (1.5%), and amiga timing slop (5%), and you can store 5999 to 6812 bytes per track, depending. So if you remove ALL sector headers, etc, you can get 959840 bytes on a disk safely (though you still need some sync marks and you really need a checksum - some recent programs haven't bothered with that and crash on disk errors). Perhaps with GCR (which the hardware manual says shouldn't be used with 2us mode, though people are using it that way) you might get a bit more, though you're still subject to those timing figures above. Things like this are why some games (particularily European) don't work on all machines: some have drives that are slightly faster spinning, or their clock rate is slightly different (crystal variation, NTSC/PAL, genlock hooked to the system, temperature, etc, etc). Some drives can handle certain uses of the interface beyond the speced performance, some barely handle our spec. Some can read past track 79, some can't. > -MEMORY: Dont you think some people apreciate > to be able to buy software > for their 512K machine!!! I hope so. Then again, in the US a LARGE proportion of people have 1M or more. Perhaps 30-50% of people who actively buy software nowadays have HD's in the US. (Numbers pulled out of a hat.) > -HD INSTALABLE: There is absolutly no > barrier for that for any floppy games. > Well only piracy. Then they should do it. > Well not everybody do simple games like > you! > People could ONLY take your advice > seriously if you actually done serious > coding and know whats involve.From what > you write in your 4 letters > I seen a LARGE lack of knowledge. > Yes, Like the Bitmap Brother, the people > at Rainbow Art, Inerprise etc etc.. > dont know all about the stuff you are > saying! Often they don't (or aren't allowed to make use of it). Many Euro-games are written so the same code (with some conditional assembling) runs on the ST and the Amiga. Needless to say, this encourages them to ignore anything on the Amiga that isn't on the ST. ALso, a number of the programmers are more used to the ST, and may not know (or care) about such things (I've gotten personal letters (snail-mail, no less) from people like this. The company wouldn't even pay for RKMs, let alone joining the developer program.) Mike can defend himself, but you should remember he's a LONG-time game programmer. [ After this, the message ends up with such a distorted margin it's essentially unreadable... ] -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
farren@well.sf.ca.us (Mike Farren) (03/26/91)
I refuse to include 1400+ lines, each of which consists mostly of spaces. Mr. Schraem, I hope that your programming skills exceed your posting skills. I was not saying that "all game programmers are ignorant". I AM saying that most of them are lazy. You make no points with me with your claims about the disastrous effects of the multitasking, since all of your points are rather easily rebutted. You make negative points with me with your flaming me for not having done enough game development. I have been a game developer since 1978. I have over thirty PUBLISHED products. Can you say the same? I have developed for everything from arcade games to Apples, from Macs to HP laptops. Can you say the same? I believe that my credibility is high. A project with 15,000 hours? If you are talking about your own personal hours, a bit of math shows pretty clearly that your claim is, shall we say, overblown. That's 1,500 10-hour days. That's five YEARS of full-time work, and I say that any project that takes five years to complete is wrong. If, on the other hand, you're talking about the number of hours I've spent as a programmer, simply take the 22 years I've been doing it, multiply by about 2 to 4 hours a day, on average, and you'll come up with a pretty impressive number yourself. -- Mike Farren farren@well.sf.ca.us
milamber@caen.engin.umich.edu (Daryl Scott Cantrell) (03/27/91)
In article <1991Mar24.204206.11145@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: >[...] > > -MULTITASKING: Have you EVER monitored the system! > Move your mouse around, moving the mouse take more than > 20% of the > CPU time! 1%? Why do you want to multitask if you use the > CPU 1% on > the other side! And puting the OS to sleep and waiking > it UP is the closest > you can get to it with this kind of game. > Here also make TurricanII or XENONII or OVERDRIVE > etc.. true multitasking. Of course, those of us with accelorated machines would appreciate being able to use the full horsepower of our computers. Even if you only leave 1% of the system to 500 owners, that's a big plus to 680[2,3]0 owners. If you're worried about slowdown you could run at pri 1.. But most game designers won't even go so far asto put the system to sleep. > -MEMORY: Dont you think some people apreciate > to be able to buy software > for their 512K machine!!! I hope so. I can understand that no game designer wants to make a 1 MB+ game and lock himself out of a large market. But at the same time, making the game only USE 512K is nothing but laziness. Making the game only WORK on 512K is sheer idiocy.. > -HD INSTALABLE: There is absolutly no > barrier for that for any floppy games. > Well only piracy. Wake up and smell the coffee.. All these wonder-protection-schemes you game designers come up with don't mean squat to 15-yr-olds with nothing better to do. Look at Dragon's Lair. Supposedly one of the best-pro- tected games published (I wouldn't know, not my kind of game..). Not only was I hearing about cracked versions out before it was even re- leased, they added insult to injury by adding features to it! The only thing your floppy protection schemes accomplish is to bug people like me into not buying your game because it can't be put on my HD. >[At this point he babbles at some great length (and very little width) >about some strange project, assembly routines, the phase of the moon >relative to Venus, and lord only knows what..] I think the most blatant indicator of how lazy most game programmers are is the neato custom disk-loaders most of them use. Even if you accept that one track on the disk should be "messed with" for copy-protection (I don't), trackdisk.device achieves transfer rates approaching the physical limits of the floppy drive. Yet game designers almost always "roll their own", and invariably 50% of them will use a CPU loop to time the raw track read. Is this for the sake of "state of the art" games? I say it's unadorned laziness. -- +---------------------------------------+----------------------------+ | // Daryl S. Cantrell | These opinions are | | |\\\ milamber@caen.engin.umich.edu | shared by all of // | | |// Evolution's over. We won. | Humanity. \X/ | +---------------------------------------+----------------------------+
sschaem@starnet.uucp (Stephan Schaem) (03/27/91)
Ok, let me first repost the first reply and then I will take you on
your this lasts ones.!
('m not a VI user! I'm a CED user.And the only way I found to make
asci file dont screw up is use a escape S after each crl J.!)
Sory, I'm a ignorent when it come to VI usage! That is true :-)
Lets see about the rest...
This is post only on the programer side and is a reply of the tutorial
writen by Mike Farren.
I really hope you have time to read the following.You might find that
game
programer are not all ignorant people like Mike Farren want us to
beleive!
After reading his 4 part Attack/leason on game programing I had to prove
something...
>(Mike Farren):
>even more, I hope that game programmers will take a
>hint or two - leave us our Amigas, please!
Dont I feel a little pretention here.I dont like that, especially
when you attack other people! especially my profesion.
First a VERY few things I wanted to comment on your posting.
-ROM CODE: Sure it was designed to make action games:-).
It can be used for it but it's not made for it!
Try to do intensive copper activity with the system function!
Try to do anything the rom was not design for!
-DISPLAY: Some game actually need steady frame rate.
Ok, now that you got trought Lemings can you write the same sugestion
with TurricanII or SW-IV or OVERDRIVE etc...?
-MULTITASKING: Have you EVER monitored the system!
Move your mouse around, moving the mouse take more than 20% of the
CPU time! 1%? Why do you want to multitask if you use the CPU 1% on
the other side! And puting the OS to sleep and waiking it UP is the
closest you can get to it with this kind of game.
Here also make TurricanII or XENONII or OVERDRIVE etc..
true multitasking.
-DISK FORMAT: 980K? not 1035K? (why have they step down?)
Right now you can get over 1.1 meg, but
not with the system. And 1.7 meg with data crunching included in the
driver ... So 880K VS 1.7 MEG!
You can have 2.4 meg disk messing around with MFM clocks, not safe...
Also Game like SW-IV or OVERDRIVE use the drive has virtual memory.
So 512K user can have 1MEG quality games!
-MEMORY: Dont you think some people apreciate to be able to buy software
for their 512K machine!!! I hope so.
-HD INSTALABLE: There is absolutly no barrier for that for any floppy
games. Well only piracy.
>BLABLABLA....
>I hope that these postings have been useful fuel for thought. I hope
>even more that any fledgling game developers reading this will think,
>the next time they do a game, about how simple it can be to have both
>a good game and an Amiga-friendly game. You don't have to give up
>much of anything, and you gain the respect and admiration of those who
>like to use their computers to their fullest, while not losing the
>respect of those who don't care.
Well not everybody do simple games like you!
People could ONLY take your advice seriously if you actually done
serious
coding and know whats involve.From what you write in your 4 letters
I seen a LARGE lack of knowledge.
Yes, Like the Bitmap Brother, the people at Rainbow Art, Inerprise
etc etc..
dont know all about you are saying!
Ok, what would you sugest to make my curent project 'more
Amiga-friendly'?
Maybe the following will tell you that other game programer KNOW
what they are doing! and what is realistic.
OVERDRIVE curently run from my HD, I can install it in memory
(making it resident!) and play anytime I want without loading
anything...
So if I use DPaint III I just press a key to enter the game and onother
key to return to DPaint.
Even if the comercial version is only on disk and connot be resident, we
are thinking of making the developer version available.Well if we
survive
that money pit!
Games can be complex.We started a Ground Zero, with DevpacII, CED,
DPIII,
soundtracker and our life investment! nothing less, nothing more.
NOTE: CED PRO and DevpacII are actually PERFECT Product.People at
MICHTRON and especially CYGNUS can be respected!
(we also have the backbone for a mutliprocessor compiler, for precessor
type code convertion)
For example that's what involved in OVERDRIVE:
-A Duplicator driver for the Amiga ONLY, with function not found on ANY
other pro system.
(We are thinking of making a commercial version).
-A Disk languages was created for developing OVERDRIVE.
The language have more than 80 instruction.like those:
TYPE
Specify the file type.
Three types are available: EXTRAC, DISK, GAME, CREATE
and COMPACTOR.
The first one allow you to extrac data from files.
The second allow you to create a disk format. Each track can be
created with it. (Each track should be... See TRACK
instruction)
Each type you want to use this disk write TYPE DISK "name".
The third allow you to create a game disk.
The forth take a soft disk created with GAME and write it on any
units you want... You have to specify the disk name to be used.
The fifth allow you to compact or convert some files.
PICTURE (EXTRAC)
This allow you to define picture decompactage.
Four decompactage are available:
NORMAL (Default)
RAWBLIT
SPRITE4
SPRITE16
HARDCOMP
SIZE Allow you to save size
NOSIZE (Default)
PIXEL X size written in pixel
WPIXEL (Default) X size written in
WordW..
WORD X size written in word
BYTESIZE Size written in a byte
..
WORDSIZE (Default)
CTRL (Default) control word in sprite
NOCTRL
REMAP
NOREMAP (Default)
SYNC (DISK/GAME)
Synchronisation is four hexadecimal number.
In GAME mode:
Define synchronisation to use for next file in GAME mode.
Then it can be at any offset in track.
In DISK mode:
This define synchronisation of actual track.
You can write SYNC+ to reach next track after you have define
sync
of this track. (Note: If end of disk is reached no track will
be
defined, and then you will need to use TRACK instruction again)
This last way suppose you already define a track number.
And it's very usefull when it's use at the end of a track
definition!
Note that the step is always 0.5...
ETC...
So heres a little programe to extract a directory with IFF brushed:
(of course the language is interactive).
Type Extract
Picture Size
Picture RawBlit
Depth 6
IffDir Picture Ram:
-A Floppy disk driver for virtual memory.
Sory Private information.But beleive me its good.
-A Compacting algorithem.
LZH is better... But I will get back to it! Including data type
detection (using diferent algorithem for 8bit digit and text for
example)
-A Powerfull MAP Editor with literaly hundreds of functions.
For example one of the selection screen of the editor has 53 functions
for map manipulation and 35 for curent brush manipulation (GADGETS).
All have key shortcut.
Of course alot of gadget have sub window:like the filer option offer
7 other option.
You can have an 'infinity' of brushes, with pattern fill with patterns.
Multiple windows (having your ANYSIZE block screen next to your map,
see multiple part of the map etc...)
Of course you can do everything other editor do, save every single
seting and configuration of the software.
Of course everything file we read or write support iff.
And Data manipulation are VERY powerfull.
You have color manipualtion screen with mixing, sorting, remaping
import/export etc... ColorCycling screen...
Information screen.Where you can set the block info.Like level, type,
Ttype, borders.(Let you modify system block info: superinfo, animation
display type: rotation, xflip, yflip etc...)
You can call an info screen and place it at the bottom to have a
scall down of your screen/map with your location...
And the editor can have multiple maps and block.
AND alot more....
-A 290 functions library.Here is some of them...:
We have resource tracking, error tracking, data check, structure
check, debug function, function check etc...
LIBINIT
;The CSD Console
LIBDEF _OpenCSDConsole
LIBDEF _CloseCSDConsole
LIBDEF _CSDWrite
LIBDEF _AnalyseString
........
LIBDEF _WOpen
LIBDEF _WClose
LIBDEF _WaitW
LIBDEF _GetWMsg
LIBDEF _ExecuteW
The above handle 100% of the overhead for you, simple plug the
structure!
Of course you can KILL a CSD task with 100% of the resource restored.
Analize string handle ansi text (not to mention).
We also have another text control sequence for special display and
calculation.
We also document the function:
;---------------------------------------------------------------------
CSDAllocMem
NAME
CSDAllocMem - Allocate memory for CSD usage
SYNOPSIS
MemBlk = CSDAllocMem(ByteSize, Requirements, StartPtr, EndPtr)
SR/D0/A0 D0 D1 A0 A1
D1
FUNCTION
This routine use ROM structure but don't go trough the Allocate
function of ROM.
This routine is made to "understand" largest flag bit. Also it's
now easily possible to allocate the largest part of memory. But
in this case you must always specify D0 like block size. (Also
you will look for the largest block under D0 or with D0 size)
Normaly if largest bit is set you will receive some memory...
To have the largest possible block you will set D0 to null or
-1.
To end, D1 is returned with the size of allocated block.
When FORCE and/or MEMABS bit are used A0 and A1 are needed to
have a good allocation. A0 define the less start address of
allocation and A1 the higher one. If MEMABS is specify also
only A1 is usefull
and define start address. (Like in ROM 1.x)
At this time LARGEST bit and FORCE one couldn't be used at the
same time.
All the CSD memory allocations are linked togheter. Also if you
force to free all your allocated memories, CSD will do it for
you. (NOTE:
a requester will appear at the end when you will make the
CloseLibrary)
INPUTS
ByteSize - Length of memory to be allocated (Long word)
Requiments - Defined type of memory (Largest allowed)
PUBLIC All allowed memory for every tasks.
CHIP Special processor memory.
FAST 68000 memory only.
CLEAR Return cleared memory.
LARGEST Allocation of 8 bytes of memory to D0 bytes.
FORCE Allocation of memory between A0 and A1 pointers.
MEMABS Allocation of memory at address A1.
RESULTS
MemBlk - Pointer to the allocated memory (Already
returned
in A0)
SR z - z is set correspondly to the result. If no
allocat
was done z will be zero, atherwise it will be
set.
SizeBlk - Return size of allocated block, this must be use
to know block size after an allocate with the
larg
bit specification. If no allocation is done
(With
not Largest bit) D1 will be null
EXECPTIONS
If length is null and largest bit is clemory
is allocated.
If length is null and largest bit is set the largest actual
memory is allocated.
Start and end addresses are reorder. Then you can send them
in any or
BUGS
Don't return 0 in D1 when allocation is not done and largest
bit is n (But return size..)
SEE ALSO
CSDAllocMemError()
CSDFreeMem()
CSDMemList()
CSDTypeOfMem()
;----------------------------------------------------------------------
AllocListSize
NAME
AllocListSize - Try to alloc memory and add it to a list
SYNOPSIS
Node = AllocListSize(List, ByteSize)
D0 A0 D0
FUNCTION
This function look for memory (Always cleared and public) and
if memory was allocated, add it in a list and then the size is
written in structure at the next position of "previous"
pointer.
Then you will be able to use this with FreeAllList() and a size
of 0.
A0 can be null if no list was already created.
If not enough memory is present also no list will be adding.
NOTE: the list is insert with InsertList routine (See).
INPUTS
List - List pointer (Null for none)
ByteSize - Size in byte of the allocated list node
(Note the size must contain the height byte of
next and previous pointers of the beginning)
RESULTS
Node - Pointer to the added node
EXCEPTIONS
None
NOTES
A list of this type is formed with a Next pointer a Previous
pointer and a word Size. Then you will be able to use the
structure from the byte ten.
BUGS
None know
SEE ALSO
AllocList()
AllocLargeList()
CountList()
CountEndList()
FreeAllList()
FreeEndList()
FreeList()
HeadList()
InsertList()
NextList()
PreviousList()
QueueList()
RemoveList()
SearchList()
SearchNextList()
All the our code are written in HIGHLY optimized assembly,
Fully multitasking, Very structured....
We have pure code, READ only.Well We want to creat an operating
system:-)
And of course there is ALOT more than the above.
65xx, I remember doing a 1024 byte full text editor with disk support...
But remember the 68000 is not a 6510, and graphics on 8bit machine is
something else!
MEMORY:
-------
-DRAWINGS: Each level has more than 400 IMAGES of 16 pixel minimum and
50% in 16 colors and the rest full 64 colors!
-MAPS: With 1024 Tiles of 16x16 in 64 colors for the map drawings.the
map has big has 400 screens.Each block have control many words to
tell the way they will be displayed, the way they are compacted,
but colors blocks etc..
Those maps are 578K big with 160K of tiles: 738K already!
-SOUND: 64K dedicated to sound and musicCREEN: 88K for the 64 colors
half bright screens.
-Each Fire (25 diferents) have buffer for up to 32 on screen.
Fire have speed, aceleration, power, efect type, direction, animation..
-OBJECT: You have to fill the 400 screens with something! you can get
more than 100 moving object on screen...
Each Object Have their own:
SHADOWS Showing their height position.
POWER For weapon protection and colision.
WEAPON Type (see above), plus programed types.
TRAJECTORY An internal interpreter, With the most used math function.
ANIMATION Can be set by trajectory interpreter and many other ways.
LINKAGE Object can be linked one another.
EXPLOSION 5 type, up to 64x64 pixels.
And alot more...
We have more than 80K of structure definition...
ETC...
I could write megs to explain the all game functions!
OVERDRIVE use almost every bytes of those 512K! That's why its
3 months late now:-( Almost everything is compated during game play
(not the sound or code)
And if we knew that we could have made a 1meg version without loosing
money 4 peoples wouldn't have developed for it for 1 1/2 years! We are
STRONG AMIGA beleivers, and we get kicks writting ANYthings at least
that it run on an AMIGA.
Some of my good friends, like The creator of LightQuest and 5 others
amiga games have to do PC, atari version too! He can program at the
hardware level on 6 machine, but will get nothing by lEARNing the Amiga
OS... See my point?
DISK:
-----
Actually I would say that the DOS we are using in OVERDRIVE is safer
than
AmigaDos!! So please...
(Already talk about that, checksum done in read buffer).
MULTITASKING:
-------------
I also have a project started: a Multitasking game running a 60 frames
second scroling in 32 colors.The scroll and interface work, so you could
say that multitasking is possible... Its not an action game, so the
system have enought time to run smothly.(A CLI scrolling and game
scrolling work nice together.)
CONCLUSION:
-----------
Actually some people other than you know the Amiga.And if you want to
tell them what to do, put them down, give them lessons you better check
that the 'student' dont know more than the 'teacher'....
dont make decision just like that! And if games dont multitask
or are not HD installable dont mean that the developers are BRAIN DEAD
and dont know the amiga!
You text being published, that would hurt!
Stephan Schaem.
NOTE: Have you ever passed more than 15,000 hours on a single project?
sschaem@starnet.uucp (Stephan Schaem) (03/27/91)
15,000 hours a TEAM a 4 experience games maker... Yes some people work that mutch! Everyone that worked on overdrive done other commercial games. And we started a year and a half ago! and still getting the last things ready now!. You could work ALL your life and not do anything good!? Is this a good point? I dont think so... Also we are system programers, and I'm pretty sure (if you want to get personal) that we know more than you on EVERY amiga subject!. We work on the amiga this the A1000 came out... Before that we worked on 8bit.(AplleII, C64, Z81, sepctrum, ORIC, MSX etc etc...).But we got passed that (I didn't worked myself on 8bit comercialy). All my point are PROVEN! please attack them one by one, and I will be GLAD to explain in more depth... Excuse me to say what I think but: You dont know what you are talking about! You are a game programer true, but you should realize that you have more than 1 kind of game! And you cant force other to follow your idea. If you have ported a MAC game and seem pretty proud of it: is the copper exploited to its fullest? is the blitter exploited to its fullest? CPU intensive? MEMORY hungry? etc... I'm not saying that you do a bad job... simply that what you do is not what other do, and you can aply rules in both worlds! So MR.KNOW EVERYTHING. Tell me how I will make my game HD instalable... Stephan.
sschaem@starnet.uucp (Stephan Schaem) (03/27/91)
c>I refuse to include 1400+ lines, each of which consists mostly of spaces. >Mr. Schraem, I hope that your programming skills exceed your posting skills. I hope you can argue better than that.... VI is not my world, have I done persoanl attack without noticing? hoops... And yes, Mr. Schaem writte better in 680x0 than English or French :-) >I was not saying that "all game programmers are ignorant". I AM saying that >most of them are lazy. You make no points with me with your claims about >the disastrous effects of the multitasking, since all of your points are >rather easily rebutted. You make negative points with me with your flaming >me for not having done enough game development. Well I dind't got that at all from your messages, it seem like you are the only one to do things right on the AMIGA. If those point are easy rebuted, please DO IT!. No, time is not the question! You haven't done the right type of development that's all! You can SAY whatever you want. I will alway say: making a GOOD action game multitasking is HARD when possible. Also do you know what you can do with those 80K used by the system!?... What about system revision.... if you got 80K on 1.0 you might have more or less next system revision! >I have been a game developer since 1978. I have over thirty PUBLISHED >products. Can you say the same? I have developed for everything from >arcade games to Apples, from Macs to HP laptops. Can you say the same? >I believe that my credibility is high. GOOD FOR YOU.Now I now you can actually make a living with program. Please name the AMIGA one that you have done... F18 interceptor, Feary Tale, TurricanII, Battle-Squadron ... are exeptional and you put down the developers of those games, saying they done it wrong and should learn for there next amiga project, everything is easy why dont they do it if they are not LAZY developers! When a software house say, 6 month project... you dont start to get FANCY. You are credible on what you do! (well you must, since you are the only one that do perfect things :-). XENONII is a jewels of programing! programing is an ART! You get into the ART with assembly language. I beleive you could have done Lemings user freindly, but not every games are of the type of lemings... Even if you labeled you tes lemings tutorial, it was clearly directed to Amiga game programer in general! >A project with 15,000 hours? If you are talking about your own personal >hours, a bit of math shows pretty clearly that your claim is, shall we say, >overblown. That's 1,500 10-hour days. That's five YEARS of full-time work, >and I say that any project that takes five years to complete is wrong. >If, on the other hand, you're talking about the number of hours I've spent >as a programmer, simply take the 22 years I've been doing it, multiply by >about 2 to 4 hours a day, on average, and you'll come up with a pretty >impressive number yourself. No, NOT MY personal hours!But a SINGLE 15,000 hours AMIGA GAME project! 4 peoples worked on the project full time.(And we are not beginers.) And 22*4*365=32120, Yoave done 2 of our project! I will only ask you one thing.And if you say YES, you are VERY credible! Here it is: On the 30 games you have published have you done 1 that is TRUE multitasking , use all the AMIGA capability to its fullest, use assembly to use the less CPU possible so the system can run faster (OS SIDE), HD instalable , and is actually a serious project, and run a a stock 1.0 512K amiga and Amiga 3000? If you think I said stupid things, please prove it to me! I can learn from my mistake, you know:-) Stephan. Stephan.
sschaem@starnet.uucp (Stephan Schaem) (03/27/91)
[ In a message formatted to make it darn near impossible to read... ] Sory, my mistake... >Mike may be many things, but I wouldn't call him ignorant. I will be more precise to corect the statement.Mike dont know everything, I didn't say he knows nothing... >Game programming is his profession also, and he's been at it longer >(unless you're older than I think you are). You think right.I'm not old at all, He even done his first game before I was even born.... I'm sure you figure it out:-) (for the one that dont know it, Mike Farren make games for 22 years now ...) But I hope I know what I'm doing, and I know who I should listen in the busness! And even if Mike can programe a 65xx better than me (maybe not my friend), I think we started on the amiga at the same time... >Fine, take over the system then. You can still return gracefully >on exit (or when paused). Also, by no means do all games need a perfectly >steady frame - Lemmings doesn't have one now, for example. True, true.But I do exit gracefully on every of my programes (only OVERDRIVE dont multitask, but return gracefully at any time). >Fine, so put it to sleep if you can't live with it. Restore it on >pause or exit if possible. If there isn't enough memory to keep from >killing it, let the user know, and if he wants to continue then take >over completely. ??? You are saying the same thing has me? Since the begining... But lets argue anyway:-)... >"Data crunching" (compression) has nothing to do with it, you can >use that regardless of the disk format. I have not seen 1035K, and >I don't believe it unless you violate the timing specs for the system >and drive (as >I published in an AmigaMail article and devcon article (low-level drive >access). The basic spec is there are (with MFM) 6250 nominal bytes of data >per track. Combine that with the amiga nominal timing (2.3% fast), disk >speed 5%), and amiga timing slop (5%), and you can store 5999 to >6812 bytes per track, depending. So if you remove ALL sector headers, >etc, you can get 959840 bytes on a disk safely (though you still need some >sync marks and you really need a checksum - some recent programs haven't >bothered with that and crash on disk errors). Perhaps with GCR (which the >hardware manual says shouldn't be used with 2us mode, though people are >using it that way) you might get a bit more, though you're still subject >to those timing figures above. Sory I must have missed something. 6812*2*80=1089920.... OK. 300RMP, 4 bytes every 63.5 microsecond THATS IT! You dont need to do fancy calculation! I CANT say anything publicly, but we dont do 'illegal' tricks... We test on various drive (from 8 diferent compagnies) 4 diferent amigas (NTSC,PAL,68000 to 68030, A500,A1000,A2000 (A2630), A3000). We do ALWAY checsums and everything we read... Right now the ALL INDUSTRIE should supose you have 300RPM (speed ajusted) drive.So you designed for 300 rmp drives... I dont have acceptable margin, but the tolerances are 'wide'. If you want to talk about the subject, E-MAIL only, please... >Things like this are why some games (particularily Euroean) >don't work on all machines: some have drives that are slightly faster >spinning, or their clock rate is slightly different (crystal variation, >NTSC/PAL, genlock hooked to the system, temperature, etc, etc). Some >drives can handle certain uses of the interface beyond the speced performance >some barely handle our spec. Some can read past track 79, some can't. Sory to say that but you should have a standart drive!Now the industrie produce ONLY drive with 'internal' motor speed control and ajustment! So you have 300 RPM drive. I cant speak for them! but if our software dont load, you have a VERY bad drive! We try with LARGE speed variation and it alway pickup the data corectly. No, people to custom track sizing! messing up with MFM coding!!! Using table coding. Also you have MFM data compacting... wio 1 ratio instead of 2 to 1.... >Then again, in the US a LARGE proportion of people have 1M or more. >Perhaps 30-50% of people who actively buy software nowadays have HD's in the >US. (Numbers pulled out of a hat.) And again when you have LARGE project like use, you loose money with the US alone.Even when you target 100% of the machine!!!!! That's what happen on big AMIGA project! >Then they should do it. Well PIRACY is the key... From my part its a maybe! if more than 2 people in the ALL AMERICA want HD support, I might considered it... >Often they don't (or aren't allowed to make use of it). Many >Euro-games are written so the same code (with some conditional assembling) >runs on the ST and the Amiga. Needless to say, this encourages them to >ignore anything on the Amiga that isn't on the ST. ALso, a number of the >programmers are more used to the ST, and may not know (or care) about such >things (I've gotten personal letters (snail-mail, no less) from people like >this. The company wouldn't even pay for RKMs, let alone joining the >developer program.) Are we talking about quality amiga product? Well, when the amiga will sell more then 20,000 copies world wide for the best game of the moment they might be some consideration!? Why that NON interest in amiga in europe? its like saying, why some people do GENESIS prgram?! Also! stunning has it can be! th WORST EVER amiga developers go to DEVCON! perosnally receive the 2.0 doc from CBM president of the concerned contrie! etc etc... And only do PC port over the amiga that dont use anything amiga at ALL! and trash the OS and rewrite BAD disk function that cause return in LARGE number!.... I spoke everyday with people at OCEAN, UBI SOFT, TITUS, SILMARIL, ECLIPS, EXPONANTIA ETC... And work for one of those compagnies for some time. (AND QUIT OF COURSE:-) So you thinkknow what I'm talking about! 99% of the amiga games are developed thinking to run on a STE minimum! and written in C to go on PC! >Mike can defend himself, but you should remember he's a LONG-time >game programmer. Well I'm sure since he his older than me:-) LONG-time programer dont mean GOOD programer. (Mike not involved here, sinply the argument) Anyway at least in europe you have a choice! you can buy good and bad software:-) Stephan.
andy@cbmvax.commodore.com (Andy Finkel) (03/27/91)
In article <23835@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >overblown. That's 1,500 10-hour days. That's five YEARS of full-time work, >and I say that any project that takes five years to complete is wrong. Either wrong, or in 100% assembler :-) >Mike Farren farren@well.sf.ca.us andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "To finish the project, all we need is a derranged programmer", said Master Li. "It is fortunate indeed that we are blessed with an overabundance." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
jbickers@templar.actrix.gen.nz (John Bickers) (03/27/91)
Quoted from <1991Mar24.204206.11145@starnet.uucp> by sschaem@starnet.uucp (Stephan Schaem): > I really hope you have time to read the following.You might find that > game Bloody hard to read the accursed thing when it drifts off to the right...! Try a repost, maybe. -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
rbabel@babylon.rmt.sub.org (Ralph Babel) (03/27/91)
In article <mykes.0346@sega0.SF-Bay.ORG>, mykes@sega0.SF-Bay.ORG (Mike Schwartz) writes: > What is lazier, writing a custom set of floppy disk > drivers or calling trackdisk.device? What is lazier, > writing your own multitasking kernel or using Exec? What > is lazier, writing custom blitter code or calling > BlitBitMap()? The laziest thing one can do on the Amiga is to ignore the native OS. In your signature, you write: > Appendix A of the Amiga Hardware Manual tells you > everything you need to know to take full advantage > of the power of the Amiga. And it is only 10 pages! That's what I would call lazy (and ignorant, too)! The Amiga is much more than just the hardware. > What is not lazier is working around all the crap that the > OS puts in your way. But - as others have pointed out - in most cases even this can be done in a system-friendly way. If you want to deal with bitplanes directly instead of using a graphics or Intuition function, then you can do it! I'm not saying that _everything_ can be built on top of an Intuition screen, for example, but certainly a lot more than most game programmers would admit. The same is true for other protocols such as OwnBlitter(), GetUnit() or even the good old AllocMem(). In almost all cases it is possible to hit the hardware directly in a system-compatible way if you really want to. But most programmers simply do not know how to do it, so they ignore the rules completely and take over the machine. Ralph
sschaem@starnet.uucp (Stephan Schaem) (03/27/91)
Nope not 5 years.A year and a half (but 4 people working on it). Simply some people like chalenging project. Asembly has nothing to do with it! Expecially on a 68000 machine. Also what do you do when you need tools that dont exist! You create them.That take time if you want to do it right. I would say if we ended up with a game like any other something would have went wrong... And what do you know about the project to think it could have been done faster in C? But its true that was exesive and we will never do such project complex project again! The only thing we got out of making such a game is lost of money, but people told us Amiga games sold very well and we beleived it... Thats why we thought it would pay to investe so mutch in a game. And now I know why the majority are not interested in producing quality amiga games. Stephan.
rbabel@babylon.rmt.sub.org (Ralph Babel) (03/27/91)
In article <mykes.0368@sega0.SF-Bay.ORG>, mykes@sega0.SF-Bay.ORG (Mike Schwartz) writes: > In article <06979.AA06979@babylon.rmt.sub.org> > rbabel@babylon.rmt.sub.org (Ralph Babel) writes: > >> Move flames like these to comp.sys.amiga.advocacy or - >> better yet - to /dev/null. Thanks to Mike Farren for an >> excellent article! I hope you can sell it to a magazine. > > This discussion belongs here and nowhere else. It is directed > directly at programmers and Amiga programming issues. The only > thing that does not belong here is insults. A _discussion_ certainly belongs here, but not a _flame_ (such as Stephan Schaem's article): >> BLABLABLA.... > Well not everybody do simple games like you! > You text being published, that would hurt! > > Stephan Schaem. Ralph
dlarson@cbmvax.commodore.com (Dale Larson) (03/27/91)
In article <1991Mar27.012717.11541@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: >Well PIRACY is the key... From my part its a maybe! if more than 2 >people in >the ALL AMERICA want HD support, I might considered it... Make Farren seems to be 1. I am 2. I've probabably purchased more than two dozen Amiga games during the last year or two, and with exactly one exception (Lemmings) all of them work on my HD or cost less than $15. If a game costs more than about $15, I find out whether it has disk copy protection (it's not worth the hastle if it's already in the bargain bin). I almost didn't buy Lemmings because it has disk protection, and I have passed up several other games for this reason. -- Dale Larson dlarson@cbmvax.commodore.com I work at Commodore-Amiga, not for Commodore-Amiga. "Oh, its not my module? That should be easy to implement." -bj "I'm not dumb but I don't understand..." -The Kinks
<DXB132@psuvm.psu.edu> (03/27/91)
In article <1991Mar27.175514.25590@cunixf.cc.columbia.edu>, es1@cunixb.cc.columbia.edu (Ethan Solomita) says: > And to tag onto the list, I too want HD support. I could >never understand why these companies refuse to support it. Some >of the WORST parts of these action games that insist upon taking >over the computer are the time spent waiting for the disk to >load. I don't want to wait! That's why I bought a hard drive! >Shadow of the Beast would be truly excellent if you didn't wait >for a few minutes every time you enter or exit something. But in your previous post you said Beast needed all 512K! And if you still want hard drive support, you must consider... * 1. Save the lower 512K in unused fast RAM (assuming its available) and swap in as neccessary. 2. Write drivers for all hard drives, like AmaxII (Dragon's Lair also supported one HD this way). Neither is a really good solution. Mike also mentioned (uh, hope you know which Mike :-) some help from the OS people. I wonder what C= does on CDTV ??? -- Dan Babcock >>Internet (Milnet): >schweige@taurus.cs.nps.navy.mil >>****************************************************************************** >* > -- Ethan >Q: How many Comp Sci majors does it take to change a lightbulb >A: None. It's a hardware problem.
mykes@sega0.SF-Bay.ORG (Mike Schwartz) (03/27/91)
In article <20115@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1991Mar24.204206.11145@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > >[ In a message formatted to make it darn near impossible to read... ] > >> I really hope you have time to read the following.You might find that >> game >> programer are not all ignorant people like Mike Farren want us to >> beleive! > > Mike may be many things, but I wouldn't call him ignorant. Stephan did not say that Mike is ignorant. It says "You might find that game programmers are not as ignorant as Mike Farren would lead you to believe." I don't think Mike is ignorant either, but he may have a tendancy to insult people who don't agree with him. > >> >(Mike Farren): >> >even more, I hope that game programmers will take a >> >hint or two - leave us our Amigas, please! >> >> Dont I feel a little pretention here.I dont like that, especially >> when you attack other people! especially my profesion. > > Game programming is his profession also, and he's been at it longer >(unless you're older than I think you are). > No need for a pissing contest. There are lots of kinds of games, and Mike is good at the kind he makes and Stephan is good at the kind he makes. I would venture to say that neither is good at the kind the other makes. >> -DISPLAY: Some game actually need steady frame rate. > > Fine, take over the system then. You can still return gracefully >on exit (or when paused). Also, by no means do all games need a perfectly >steady frame - Lemmings doesn't have one now, for example. > >> -MULTITASKING: Have you EVER monitored the system! >> Move your mouse around, moving the mouse take more than >> 20% of the >> CPU time! 1%? Why do you want to multitask if you use the >> CPU 1% on >> the other side! And puting the OS to sleep and waiking >> it UP is the closest >> you can get to it with this kind of game. > > Fine, so put it to sleep if you can't live with it. Restore it on >pause or exit if possible. If there isn't enough memory to keep from killing >it, let the user know, and if he wants to continue then take over completely. > What is the commodore approved way of doing this? Show us some code that takes over all 512K on a 512K machine and returns back to the OS! Make sure it is guaranteed to work and make sure that it doesn't need to swap to disk. > [ stuff deleted about high density formats possible on floppy ] > Things like this are why some games (particularily European) >don't work on all machines: some have drives that are slightly faster >spinning, or their clock rate is slightly different (crystal variation, >NTSC/PAL, genlock hooked to the system, temperature, etc, etc). Some >drives can handle certain uses of the interface beyond the speced performance, >some barely handle our spec. Some can read past track 79, some can't. > You point is quite valid. But it is not the only way to look at things. Consider that software can break for many reasons besides floppy disk driver code. If you use self modifying code, it breaks on CPUs with a pipeline or cache. If you jump directly into ROM routines with hard coded addresses, the routines might be at a different address in a different version of the ROM. A program might use the CPU for timing, which doesn't work the same for all CPUs (this can also break floppy disk drivers). The 68000 uses only 24 bits of address, so it is possible to use the upper 8 bits of addresses in RAM and in registers for flags or other data - this breaks on the 020 and 030. The things I mention will break software, whether it is written to run under the OS or when taking over the machine. Pointing at badly written software that takes over the machine is not a valid reason to discourage people from taking over the machine. It is a valid reason to encourage people to write code correctly so it works on all machines though. >> -MEMORY: Dont you think some people apreciate >> to be able to buy software >> for their 512K machine!!! I hope so. > > Then again, in the US a LARGE proportion of people have 1M or more. >Perhaps 30-50% of people who actively buy software nowadays have HD's in the >US. (Numbers pulled out of a hat.) > Let me pull some numbers out of a hat, too. Based upon your figures, if 30% of US buyers have HD's, that makes about 60,000 machines out of a total greater than 2,000,000 worldwide. If you are lucky, a hit piece of game software will make 5% market penetration. We are talking about 3,000 potential customers. Even if NONE of these 60,000 people buy your game and you still get 5% market penetration for those that are left, you get 97,000 machines. You also caveat your estimates by saying "those who buy software", so it is even more dismal. Factor in the piracy rate and the incentive to worry about hard disks is nominal. It is a huge mistake to look at Usenet interest in hard disk installable games. People who use Usenet are typically power users. Unix does not work from floppy disk like AmigaDos does. There are also maybe a couple of hundred people (I suspect even less) who even read these newsgroups. They are far from representative of the TRUE customer base. >> -HD INSTALABLE: There is absolutly no >> barrier for that for any floppy games. >> Well only piracy. > > Then they should do it. Not enough incentive. > >> Well not everybody do simple games like >> you! >> People could ONLY take your advice >> seriously if you actually done serious >> coding and know whats involve.From what >> you write in your 4 letters >> I seen a LARGE lack of knowledge. >> Yes, Like the Bitmap Brother, the people >> at Rainbow Art, Inerprise etc etc.. >> dont know all about the stuff you are >> saying! > > Often they don't (or aren't allowed to make use of it). Many >Euro-games are written so the same code (with some conditional assembling) >runs on the ST and the Amiga. Needless to say, this encourages them to >ignore anything on the Amiga that isn't on the ST. ALso, a number of the >programmers are more used to the ST, and may not know (or care) about such >things (I've gotten personal letters (snail-mail, no less) from people like >this. The company wouldn't even pay for RKMs, let alone joining the >developer program.) > This is not just true of European developers. EA likes to port their stuff around just as much, and they are the biggest publisher/distributer in the US. I urge you to check out ST games and compare them with Amiga games. The games on the ST are quite impressive, even though the machine doesn't have all the great hardware the Amiga has. Custom hand crafted assembler language programs on the ST that take over the machine work better than 'C' programs running on the Amiga under the OS. I hate to say anything that puts down the Amiga and hypes up the ST, but I also am not stupid enough to bury my head in the sand. The bottom line is that anything the ST can do, the Amiga is capable of doing better. The fact that the Amiga doesn't do better is a result of a better approach to implementing the games on the ST. > Mike can defend himself, but you should remember he's a LONG-time >game programmer. > I prefer discussion over insults anyday. I think that Stephan is responding only to what he perceives as critical/insulting statements made by Mike. >[ After this, the message ends up with such a distorted margin it's essentially > unreadable... ] > Stephan is from France. He has been in America for 3 years. His spoken english is much better than is written english is. It may look like he is illiterate, but he is actually quite sharp. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >Thus spake the Master Ninjei: "To program a million-line operating system >is easy, to change a man's temperament is more difficult." >(From "The Zen of Programming") ;-) -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
mykes@sega0.SF-Bay.ORG (Mike Schwartz) (03/28/91)
In article <23835@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: > >I refuse to include 1400+ lines, each of which consists mostly of spaces. >Mr. Schraem, I hope that your programming skills exceed your posting skills. > >I was not saying that "all game programmers are ignorant". I AM saying that >most of them are lazy. You make no points with me with your claims about >the disastrous effects of the multitasking, since all of your points are >rather easily rebutted. You make negative points with me with your flaming >me for not having done enough game development. > What is lazier, writing a custom set of floppy disk drivers or calling trackdisk.device? What is lazier, writing your own multitasking kernel or using Exec? What is lazier, writing custom blitter code or calling BlitBitMap()? What is not lazier is working around all the crap that the OS puts in your way. The bull that I see competent programmers on other machines do on the Amiga using the OS (like writing directly into the workbench bitplanes to recover memory) is apalling. >I have been a game developer since 1978. I have over thirty PUBLISHED >products. Can you say the same? I have developed for everything from arcade >games to Apples, from Macs to HP laptops. Can you say the same? I believe >that my credibility is high. > Something that hurts your credibility is inflamatory statements that you tend to make when someone doesn't agree with you. I have been a game developer since 1973. I have over thirty PUBLISHED products, too. I can say the same. I have developed everything from arcade machines, to apples, to C64s to Macs, and VCS and Genesis, too. My credibility is just as high based upon your criterea. Experience doesn't make you right (or me either). I hate pissing contests, but it looks to me like we are both right to a large degree. Some games can be done without the OS and some can be done with it. There is no need to make a game like HACK or LARN run without the OS. But there is also no reason for a game like Shadow of the Beast to work under it. Some of us are into performance, and some are not. >A project with 15,000 hours? If you are talking about your own personal >hours, a bit of math shows pretty clearly that your claim is, shall we say, >overblown. That's 1,500 10-hour days. That's five YEARS of full-time work, >and I say that any project that takes five years to complete is wrong. >If, on the other hand, you're talking about the number of hours I've spent >as a programmer, simply take the 22 years I've been doing it, multiply by >about 2 to 4 hours a day, on average, and you'll come up with a pretty >impressive number yourself. > Two points. Madden Football on the Apple II took 5 years. And 7 people working full time can put in 15,000 hours in one year (at 40 hours per week). My advice to you is to try to be a little less abrasive. When you post thousands of lines of biased opinions, you can expect to get flamed in response. This is the main function of usenet :) If you can't stand the flames, get out of the kitchen. >-- >Mike Farren farren@well.sf.ca.us -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
plouff@kali.enet.dec.com (Wes Plouff) (03/28/91)
Boyohboy! Mike Farren makes some carefully reasoned conjectures and the flamefest begins! He spins out a WHAT IF scenario... what if Lemmings were designed to use Amiga standards? What compromises would be necessary? Nobody so far has refuted his arguments that the only compromises needed _might_ be a) less complicated intro animation and b) remove two visual puns on other Psygnosis games. Is this a big lose for Lemmings? IMO, no. Instead, the comment runs that Farren wants to compromise the performance of Master Raster Plaster Blaster-type action games. Read again: he specifically doesn't. The irony is that there's a very popular game in the same general class of action and computation intensity as Lemmings that satisfies Farren's entire wish list. Sim City is another breakthrough game that is totally Amiga-friendly. Even comes with two diskettes in the box for 512K and larger memory machines. So why not Lemmings? Oh, add me to the list of Americans who want HD-installable games. -- Wes Plouff, Digital Equipment Corp, Maynard, Mass. plouff@kali.enet.dec.com Networking bibliography: _Islands in the Net_, by Bruce Sterling _The Matrix_, by John S. Quarterman
mykes@sega0.SF-Bay.ORG (Mike Schwartz) (03/28/91)
In article <06979.AA06979@babylon.rmt.sub.org> rbabel@babylon.rmt.sub.org (Ralph Babel) writes: >In article <1991Mar24.204206.11145@starnet.uucp>, >sschaem@starnet.uucp (Stephan Schaem) writes: > >> [Gartenzwergperspektive deleted] > >Move flames like these to comp.sys.amiga.advocacy or - >better yet - to /dev/null. Thanks to Mike Farren for an >excellent article! I hope you can sell it to a magazine. > >Ralph >-- >"Surprising what you can do when you use the OS ..." - Randell Jesup This discussion belongs here and nowhere else. It is directed directly at programmers and Amiga programming issues. The only thing that does not belong here is insults. -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
es1@cunixb.cc.columbia.edu (Ethan Solomita) (03/28/91)
In article <21510@shlump.nac.dec.com> plouff@kali.enet.dec.com (Wes Plouff) writes: > >Boyohboy! Mike Farren makes some carefully reasoned conjectures and the >flamefest begins! He spins out a WHAT IF scenario... what if Lemmings >were designed to use Amiga standards? What compromises would be >necessary? Nobody so far has refuted his arguments that the only >compromises needed _might_ be a) less complicated intro animation and >b) remove two visual puns on other Psygnosis games. Is this a big lose >for Lemmings? IMO, no. > It seems the problem here is that everyone is screaming that the others are wrong and then proceed to argue on a totally different subject. My question is: What about Shadow of the Beast type programs? How far should/could Psygnosis have gone with SOTB to make it Amiga-friendly? It doesn't seem to be the most amenable of games to the OS. It must play some NASTY copper-list tricks, and probably does need every ounce of memory on a 512K system. -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
schweige@aldebaran.cs.nps.navy.mil (Jeffrey M. Schweiger) (03/28/91)
In article <1991Mar27.012717.11541@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: >Well PIRACY is the key... From my part its a maybe! if more than 2 >people in >the ALL AMERICA want HD support, I might considered it... Well, I, for one, like hard drive support. I also dislike copy protection, custom operating systems, and lack of multi-tasking. By the way, if you mentionned it, I missed it, but what game did you write for the Amiga? -- ******************************************************************************* Jeff Schweiger Standard Disclaimer CompuServe: 74236,1645 Internet (Milnet): schweige@taurus.cs.nps.navy.mil *******************************************************************************
es1@cunixb.cc.columbia.edu (Ethan Solomita) (03/28/91)
In article <1998@aldebaran.cs.nps.navy.mil> schweige@cs.nps.navy.mil (Jeffrey M. Schweiger) writes: >In article <1991Mar27.012717.11541@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > > >>Well PIRACY is the key... From my part its a maybe! if more than 2 >>people in >>the ALL AMERICA want HD support, I might considered it... > >Well, I, for one, like hard drive support. I also dislike copy protection, >custom operating systems, and lack of multi-tasking. > >By the way, if you mentionned it, I missed it, but what game did you write for >the Amiga? > And to tag onto the list, I too want HD support. I could never understand why these companies refuse to support it. Some of the WORST parts of these action games that insist upon taking over the computer are the time spent waiting for the disk to load. I don't want to wait! That's why I bought a hard drive! Shadow of the Beast would be truly excellent if you didn't wait for a few minutes every time you enter or exit something. >-- >******************************************************************************* >Jeff Schweiger Standard Disclaimer CompuServe: 74236,1645 >Internet (Milnet): schweige@taurus.cs.nps.navy.mil >******************************************************************************* -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
mike_s@EBay.Sun.COM (Mike "The Claw" Sullivan) (03/28/91)
In <1991Mar27.164811.4811@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > My question is: What about Shadow of the Beast type >programs? How far should/could Psygnosis have gone with SOTB to >make it Amiga-friendly? It doesn't seem to be the most amenable >of games to the OS. It must play some NASTY copper-list tricks, >and probably does need every ounce of memory on a 512K system. And it doesn't work on my A1000+Hurricane+Rejuvenator! If it's all the same, the best games I have 1. Work on my machine 2. Don't make me disconnect any peripherals 3. Are HD-installable 4. Allow me to exit without rebooting Lately, more and more of this has been true. It used to be that 90% of the games I bought didn't even work, which can be discouraging. Now, it's up to about 70% working. However, it's still not enjoyable to hear great things about a game like SOTB, buy it, and watch it crash. It just becomes a waste of money, and tends to make me not buy from that company again. I only bought Lemmings because many people here said it worked on a 3000, was a great game, and didn't seem to thrash the disk. By the way, I am not impressed by the disk access of Budokan or the Immortal. Budokan I gave up on because it took so long to switch screens, and I thought the Immortal wouldn't boot because it takes 10 minutes to boot. Mike -- Mike Sullivan Internet: msullivan@EBay.Sun.COM Sun Education UUCP: ..!sun!yavin!msullivan Software Course Developer Compuserve: 75365,764 "The old Maxwell Smart silhouette on the window shade trick. That's the
Ives Aerts <GUTEST8@cc1.kuleuven.ac.be> (03/28/91)
Add me to the European list of ppl. who want HD-installable games.
I don't think they should all multitask (don't see Turrican do it)
but how about starting and quitting from workbench/cli. If your
game doesn't need all that wiz-bang system performance, make
it multi-taskable too.
As for stefan: you gave some weird criteria for good games:
written in Assembler, cpu intensive, memory hungry, etc.
I think those are the negative things about some good games
(sometimes you can't avoid it but not allways). The real criteria
are gameplay, gfx and sound, addictiveness, ... Granted, this
usually implies the other stuff but it's not enough for a
game to have the characteristics you mentioned in order to
be good.
------------------------------------------------------------------------
Ives Aerts | IBM definition SY-34378
GUTEST8@BLEKUL11.BITNET | A signature consists of sequences of
gutest8@cc1.kuleuven.ac.be | non-blank characters separated by blanks.
------------------------------------------------------------------------m0154@tnc.UUCP (GUY GARNETT) (03/28/91)
babylon!rbabel (Ralph Babel) writes: >Move flames like these to comp.sys.amiga.advocacy or - >better yet - to /dev/null. Thanks to Mike Farren for an >excellent article! I hope you can sell it to a magazine. >Ralph >"Surprising what you can do when you use the OS ..." - Randell Jesup Good Idea! How about adding some example code (maybe for a very small "lemmings-like" game) and selling it to a magazine like AC's Tech! If these ideas (and their sample code) were more available, I think that fewer games would be written the way that they are now. Wildstar
nv89-nun@alv.nada.kth.se (Nicklas Ungman) (03/28/91)
To:
In article <21510@shlump.nac.dec.com> plouff@kali.enet.dec.com (Wes Plouff) writes:
Oh, add me to the list of Americans who want HD-installable games.
--
Wes Plouff, Digital Equipment Corp, Maynard, Mass.
plouff@kali.enet.dec.com
Networking bibliography: _Islands in the Net_, by Bruce Sterling
_The Matrix_, by John S. Quarterman
Well, that makes it more than two people with HDs. And with the dropping
prices on HDs the number is going to increase.
/Nixxonbairds@eecs.cs.pdx.edu (Shawn L. Baird) (03/28/91)
plouff@kali.enet.dec.com (Wes Plouff) writes: >Boyohboy! Mike Farren makes some carefully reasoned conjectures and the >flamefest begins! He spins out a WHAT IF scenario... what if Lemmings >were designed to use Amiga standards? What compromises would be I think you and Mike Farren are both probably right here. Still, I wouldn't expect a multi-tasking game from Psygnosis. It just doesn't fit their style. If the demand for multi-tasking games was high enough, I'm sure they would do it. >Sim City is another breakthrough game that is totally Amiga-friendly. >Even comes with two diskettes in the box for 512K and larger memory >machines. So why not Lemmings? Personally, SimCity is one of the worst ports to the Amiga ever. The map scrolling, for example, is the slowest I've ever seen. This game reminds me of just a straight C port over with the CPU probably doing all of the graphics work. SimCity multi-tasks quite nicely, but I think the game could have been improved upon without sacrificing any of the quality or multi-tasking. >Oh, add me to the list of Americans who want HD-installable games. As someone pointed out, it is probably more likely that readers of comp.sys.amiga.programmers will have HDs to install games on. Personally, I only really mind if the game is larger than a disk. I think that most adventure games (like DungeonMaster for example) and some simulation/ logic games (like Lemmings and Sim City) could and perhaps should be able to run from the hard drive, or at least to be able to save games to it. Although multi-tasking is a plus, I don't want the quality of a game sacrificed because of it. I'd rather let it take over the machine. Inherently, there's also a bit of fun and a feeling of power from kicking out the OS. Do it yourself, and see if you can do it better! I wouldn't remove my Amiga's OS permanently, and let me say that the designers of the OS have done a very good job with 2.0, but working directly with the hardware is something that everyone should at least try. Performing your own multi-tasking and writing your own general purpose routines for blitting, etc. can be quite challenging. In the end, I wish it were a breeze to just put a button in the game that has Multi-tasking written on it, and then just be able to push the button and have the value saved in a set up on my hard drive along with the game itself, but alas, I also want the full power of the machine for games like Shadow of the Beast. Could someone please tell me what happened to Shadow of the Beast II? From what I've seen of it, it seems like the original programmer of Shadow of the Beast must have moved on to something else. Shadow of the Beast II looked, well, cheesey. Also, has anyone heard anything about the release of Armorgeddon? Is it available yet? Is it good? >-- >Wes Plouff, Digital Equipment Corp, Maynard, Mass. >plouff@kali.enet.dec.com >Networking bibliography: _Islands in the Net_, by Bruce Sterling > _The Matrix_, by John S. Quarterman --- Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD The above message is not licensed by AT&T, or at least, not yet.
mykes@sega0.SF-Bay.ORG (Mike Schwartz) (03/28/91)
In article <1991Mar26.211403.8981@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: >In article <1991Mar24.204206.11145@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: >> -HD INSTALABLE: There is absolutly no >> barrier for that for any floppy games. >> Well only piracy. > >Wake up and smell the coffee.. All these wonder-protection-schemes you >game designers come up with don't mean squat to 15-yr-olds with nothing >better to do. Look at Dragon's Lair. Supposedly one of the best-pro- >tected games published (I wouldn't know, not my kind of game..). Not >only was I hearing about cracked versions out before it was even re- >leased, they added insult to injury by adding features to it! The only >thing your floppy protection schemes accomplish is to bug people like >me into not buying your game because it can't be put on my HD. > NOBODY expects to make a game that will never be cracked. The best any one can hope for is 2 or 3 months of being able to get sales before it gets pirated. Once it is pirated, sales drop to ZERO. Once you can put software on hard disk, it will be modemed to all 4 corners of the earth at 9600 baud and you can kiss your sales goodbye. When major software publishers like WordPerfect see dismal sales, they stop supporting the machine. Have you ever heard of a pirate party? This is where a bunch of pirates get together in a gymnasium somewhere and everyone brings their hundreds of pirated disks. You get to copy anything from anyone else that you want. I had the opportunity to read about a big bust they just made in France where they confiscated MILLIONs of dollars in pirated software at just one of these meetings. >>[At this point he babbles at some great length (and very little width) >>about some strange project, assembly routines, the phase of the moon >>relative to Venus, and lord only knows what..] > >I think the most blatant indicator of how lazy most game programmers are >is the neato custom disk-loaders most of them use. Even if you accept >that one track on the disk should be "messed with" for copy-protection >(I don't), trackdisk.device achieves transfer rates approaching the >physical limits of the floppy drive. Yet game designers almost always >"roll their own", and invariably 50% of them will use a CPU loop to time >the raw track read. Is this for the sake of "state of the art" games? >I say it's unadorned laziness. > Your definition of lazy is wrong. Is it lazier to call Open(), Read(), Close() or to write the software to work the drive yourself? It is a lot of extra work that can add a lot of greatness to a product. Again, I will refer you to the routines I wrote. They require 10K of CHIP RAM for as many drives as you can have (4). If you have 4 drives, trackdisk.device eats up 40K. The trackdisk.device routines do not use the DSKSYNC capabilities of the drive. Custom loaders can improve performance by avoiding extra disk revolutions (this is done by timing when you write to the disk in the first place). There is NO EXCUSE for writing poor software whether you take over the machine or not. Commodore has gone out of its way to tell developers how to use the CIA timers instead of the CPU for timing. This is the correct way to do things. Speaking of lazy, I think it is lazy to not want to stick a floppy disk in the drive to play the game. > >-- >+---------------------------------------+----------------------------+ >| // Daryl S. Cantrell | These opinions are | >| |\\\ milamber@caen.engin.umich.edu | shared by all of // | >| |// Evolution's over. We won. | Humanity. \X/ | >+---------------------------------------+----------------------------+ -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
hill@evax.arl.utexas.edu (Adam Hill) (03/29/91)
How about a list of games each author in this "discussion" has done?
Then not only could we hear objective arguements, but WE as the
"listening public" make a subjective decsion on the quality of the
games. As long as most people don't hold a disk's protection scheme
against the author(s), since it is often done by the publishing house
(ie. Psygnosis, Electronic Arts etc...)
--
adam hill -- hill@evax.uta.edu ASOCC - University of Texas at UTA
I programmed for three days Make Up Your Own Mind.. AMIGA!
And heard no human voices. Amiga... Multimedia NOW!
But the hard disk sang. - TZoP Born To Run SVR4hgschmie@immd4.informatik.uni-erlangen.de (Henning Schmiedehausen) (03/29/91)
In <NV89-NUN.91Mar28005810@alv.nada.kth.se> nv89-nun@alv.nada.kth.se (Nicklas Ungman) writes: >To: >In article <21510@shlump.nac.dec.com> plouff@kali.enet.dec.com (Wes Plouff) writes: > Oh, add me to the list of Americans who want HD-installable games. Alright, then add me to the list of Europeans who want HD-installable games. We're not all so ignorant like Mr. Schaem. If he thinks, that he's a great programmer ok. I don't think it. And yes, programming *IS* an art! And that's why I go to CS courses :) Ciao Henning -- ONLY /// Real: Henning Schmiedehausen | Alle schlechten Dinge an __ /// INT: hgschmie@immd4.uni-erlangen.de | dieser Uni haben 3 Buch- \\\/// UUCP: henning@castle.erh.sub.org | staben: POP,IRC,DAS,LuB... \XX/ AMIGA 1500 -- UUCP 1.09D | Run and get the fire brigade... - The Move --- ONLY /// Real: Henning Schmiedehausen | Alle schlechten Dinge an __ /// INT: hgschmie@immd4.uni-erlangen.de | dieser Uni haben 3 Buch- \\\/// UUCP: henning@castle.erh.sub.org | staben: POP,IRC,DAS,LuB... \XX/ AMIGA 1500 -- UUCP 1.09D | Run and get the fire brigade... - The Move
farren@well.sf.ca.us (Mike Farren) (03/29/91)
sschaem@starnet.uucp (Stephan Schaem) writes: > 15,000 hours a TEAM a 4 experience games maker... Yes some people > work that mutch! Ah, so you've each put 1-1/2 years worth of work into something that will bring you a return of, if you're VERY lucky, $20,000 each? Sounds foolish to me, but to each his own, I guess. > Everyone that worked on overdrive done other commercial games. Name them. > Also we are system programers, and I'm pretty sure (if you want to > get personal) that we know more than you on EVERY amiga subject!. You haven't the slightest idea how much I know about ANY Amiga subject, so this is absurd. > We work on the amiga this the A1000 came out... Like I said in my first post, I worked on the Amiga when it was still the Lorraine. You don't impress me. > All my point are PROVEN! please attack them one by one, and I will be > GLAD to explain in more depth... Your points had nothing to do with what I was talking about. If you care to talk about MY points, I'll debate you. Otherwise, it's YOUR problem, not mine. > Excuse me to say what I think but: You dont know what you are talking > about! Like I said above, I don't think YOU know what I'm talking about! > You are a game programer true, but you should realize that you have > more than 1 kind of game! And you cant force other to follow your > idea. Never said I wanted to. > If you have ported a MAC game and seem pretty proud of it: is the > copper exploited to its fullest? is the blitter exploited to its > fullest? CPU intensive? MEMORY hungry? etc... I used all of the resources that the game needed as much as I needed to use them. I also left enough there so other tasks could still work. The purpose of programming isn't to be a hog of everything you can get your hands on simply because it's there, or because you MIGHT need it. > I'm not saying that you do a bad job... simply that what you do is > not what other do, and you can aply rules in both worlds! Never said you could. > So MR.KNOW EVERYTHING. Tell me how I will make my game HD instalable... How the hell should I know? It's not MY game. YOU figure out how to do it - or are you just not clever enough to? -- Mike Farren farren@well.sf.ca.us
farren@well.sf.ca.us (Mike Farren) (03/29/91)
sschaem@starnet.uucp (Stephan Schaem) writes: >If those point are easy rebuted, please DO IT!. It was not my intention to rebut your points - I was asking you to rebut mine. So far, you haven't. I don't think that you can. >No, time is not the question! You haven't done the right type of >development that's all! You can SAY whatever you want. I will alway >say: making a GOOD action game multitasking is HARD when possible. I never said it wasn't hard. I just said it was most often possible. Refusing to do something because it's hard is whining and sloth, and I cannot respect any programmer who whines. >Also do you know what you can do with those 80K used by the system!?... >What about system revision.... if you got 80K on 1.0 you might have more >or less next system revision! The 80K was measured on a standard A500 running 1.3. Since 2.0 will not run in 512K, it's not a problem. There aren't likely to be any more significant additions to 1.3. Also, one point I didn't mention - that's 80K if you leave the OS completely alone. You can do better than that. >Please name the AMIGA one that you have done... >F18 interceptor, Feary Tale, TurricanII, Battle-Squadron ... Oh, you did those games? If you didn't, then you can't use them as ammunition to support your competence. Why don't YOU name the games you've published? I suspect that it's simply because you cannot. >are exeptional and you put down the developers of those games, Where did I ever say a word about the developers of those games? Do you always act this paranoid? Those games ARE exceptional - much better than the ones I've done (Crystal Quest, Storm Across Europe, Quink, others). So what? F-18 could have multitasked, and IS HD installable with a simple patch. TurricanII is silly, lightweight, and not much of a game - although it is pretty. Faery Tale is nice, but no big thing, and I believe could have been HD installable and multitasking with no problem. This is only a putdown of the original developers in the sense that they didn't go quite far enough - with a little more effort, they could have given us everything. But you don't believe in giving the user anything, do you? Unless it's something YOU feel is necessary. >saying they done it wrong and should learn for there next amiga project, >everything is easy why dont they do it if they are not LAZY developers! >When a software house say, 6 month project... you dont start to get >FANCY. It isn't fanciness - it's fundamental. Besides, aren't you the one who's advocating 18-month projects, up there? That's enough time to write an entire OS, let alone a silly game. >You are credible on what you do! (well you must, since you are the only >one that do perfect things :-). I don't do perfection. >XENONII is a jewels of programing! programing is an ART! You get into >the ART with assembly language. What crap. XenonII is a nice piece of work, but it's hardly a piece of art. And I do assembly programming when I feel like it, so what's your point? >I beleive you could have done Lemings user freindly, but not every games >are of the type of lemings... Never said they were. >Even if you labeled you tes lemings tutorial, it was clearly directed to >Amiga game programer in general! >No, NOT MY personal hours!But a SINGLE 15,000 hours AMIGA GAME project! >4 peoples worked on the project full time.(And we are not beginers.) >And 22*4*365=32120, Yoave done 2 of our project! No, I've probably done about 5 or ten of your project - I just did them a lot more efficiently. 15,000 hours for a game project is ridiculous. >On the 30 games you have published have you done 1 that is TRUE >multitasking >, use all the AMIGA capability to its fullest, use assembly to use >the less CPU possible so the system can run faster (OS SIDE), HD >instalable >, and is actually a serious project, and run a a stock 1.0 512K amiga >and >Amiga 3000? What a crock. "Have you stopped beating your wife?". The answer, by the way, is yes. ALL of my games use the Amiga capability to the fullest extent required by the game. All of them use assembly language glue where speed is required. All of them are HD installable. All of them run on stock Amigas - although there is one bug in Storm Across Europe which causes it to malfunction under 2.0. >If you think I said stupid things, please prove it to me! >I can learn from my mistake, you know:-) You haven't shown that in the three years I've been watching you post. Your arrogance is unbelievable, and always has been. -- Mike Farren farren@well.sf.ca.us
jms@vanth.UUCP (Jim Shaffer) (03/29/91)
In article <mykes.0340@sega0.SF-Bay.ORG> mykes@sega0.SF-Bay.ORG (Mike Schwartz) writes: > >It is a huge mistake to look at Usenet interest in hard disk installable >games. People who use Usenet are typically power users. Unix does not >work from floppy disk like AmigaDos does. There are also maybe a couple >of hundred people (I suspect even less) who even read these newsgroups. >They are far from representative of the TRUE customer base. Just to nit-pick a little <grin>: We had, if I remember correctly, nearly 600 people voting for (or occasionally against) the comp.sys.amiga breakup. I suspect that, just as in real life, an even larger number of participants didn't vote at all. At one nearby university, *none* of the Amiga users voted at all, and I *know* that some of them read the Net. Also you can run Usenet on less than a HD. I'm running this private node on three floppy drives (I once did it on two!). And of course Unix isn't required. There are also BBSs that offer Usenet, both Unix and DOS-based, for those who aren't power users enough to figure out Unix. (Or just don't have any other option.) Also, even a complete idiot can use a HD if someone formats it for him. >>[ After this, the message ends up with such a distorted margin it's essentially >> unreadable... ] > >Stephan is from France. He has been in America for 3 years. His spoken english >is much better than is written english is. It may look like he is illiterate, >but he is actually quite sharp. Literate he may be, but he still hosed the message. 30K is quite a bit to read when it's 15 columns wide. *PS:* Neither my Organization: nor my sig quote were chosen for this occasion. I've had them for a long time now. -- * From the disk of: | jms@vanth.uucp | "You know I never knew Jim Shaffer, Jr. | amix.commodore.com!vanth!jms | that it could be so 37 Brook Street | uunet!cbmvax!amix!vanth!jms | strange..." Montgomery, PA 17752 | 72750.2335@compuserve.com | (R.E.M.)
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (03/29/91)
In article <1991Mar27.175514.25590@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >In article <1998@aldebaran.cs.nps.navy.mil> schweige@cs.nps.navy.mil (Jeffrey M. Schweiger) writes: >>In article <1991Mar27.012717.11541@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: >> >> >> >>>Well PIRACY is the key... From my part its a maybe! if more than 2 >>>people in >>>the ALL AMERICA want HD support, I might considered it... >> >>Well, I, for one, like hard drive support. I also dislike copy protection, >>custom operating systems, and lack of multi-tasking. >> >>By the way, if you mentionned it, I missed it, but what game did you write for >>the Amiga? >> > And to tag onto the list, I too want HD support. I could >never understand why these companies refuse to support it. Some >of the WORST parts of these action games that insist upon taking >over the computer are the time spent waiting for the disk to >load. I don't want to wait! That's why I bought a hard drive! >Shadow of the Beast would be truly excellent if you didn't wait >for a few minutes every time you enter or exit something. > >>-- >>******************************************************************************* >>Jeff Schweiger Standard Disclaimer CompuServe: 74236,1645 >>Internet (Milnet): schweige@taurus.cs.nps.navy.mil >>******************************************************************************* > > > -- Ethan > >Q: How many Comp Sci majors does it take to change a lightbulb >A: None. It's a hardware problem. I have been lobbying Commodore to solve the problem. The problem is not with the developers, but with the OS. What I suggest CBM does is to provide entry points in Exec for software that takes over the machine to access both the floppy drives and the hard disks. It is easy enough for them to do for 2.0 before it goes to ROM. The problem with hard disk support is that it REQUIRES the OS. Since all hard disk controllers have ROM on them, the controllers could easily provide the software routines needed to directly access the hard disk. Commodore should provide routines in Exec that allow AmigaDos access to the hard disk through this mechanism. Single tasking computers can do it, so can the Amiga. There is no need for Exec or AmigaDOS to be running to read the data from the drives. If Commodore provides this support, we will all see more HD Installable games, especially those that take over the machine. -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
jesup@cbmvax.commodore.com (Randell Jesup) (03/29/91)
In article <1991Mar27.012717.11541@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: >>I published in an AmigaMail article and devcon article (low-level drive >>access). The basic spec is there are (with MFM) 6250 nominal bytes of >data >>per track. Combine that with the amiga nominal timing (2.3% fast), >disk >>speed 5%), and amiga timing slop (5%), and you can store 5999 to >>6812 bytes per track, depending. So if you remove ALL sector headers, >>etc, you can get 959840 bytes on a disk safely >Sory I must have missed something. 6812*2*80=1089920.... >OK. 300RMP, 4 bytes every 63.5 microsecond THATS IT! You dont >need to do fancy calculation! No, that's 5999*2*80. You CANNOT assume you can store more than 5999 bytes per track when you write. 6812 is the maximum you can ever write (so you need a slop (gap) at the beginning of a write of 814 bytes minimum). See the article I published in AmigaMail on low-level drive access, with all the specs (and drives DO vary wildly). Other important numbers are 3ms step time, 15ms settle time (on top of the 3ms), 1200 microseconds post-write delay before deselecting or stepping or changing heads; 1000 microseconds side select delay before reading or writing. Motor on delay of 500 milliseconds OR until DSKRDY indicates the drive is up to speed. It's slightly different when mass-producing disks: so long as you don't create disks that exceed paula's sync rate, since you control the drive in the duplicator you can make sure you can write the number of bytes you want to (by running the drive slow or the duplicator fast). That number should not exceed 6812 (from above). >I CANT say anything publicly, but we dont do 'illegal' tricks... >We test on various drive (from 8 diferent compagnies) 4 diferent amigas >(NTSC,PAL,68000 to 68030, A500,A1000,A2000 (A2630), A3000). Ever check one where the owner had attached a genlock? And in any case, 4 amigas or 8 drives is a small sample. Some drives that have the most problems were only used for a short while, or a long time ago. >We do ALWAY checsums and everything we read... >Right now the ALL INDUSTRIE should supose you have 300RPM (speed >ajusted) >drive.So you designed for 300 rmp drives... >I dont have acceptable margin, but the tolerances are 'wide'. 300rpm, but we (and the manufacturers only guarantee) +- 1.5% (297.5 to 304.5 rpm). It can vary due to drive age, media type (some are rougher), temperature, etc, input voltage changes, etc. >If you want to talk about the subject, E-MAIL only, please... I think others should know these things (disk timing issues). >>some barely handle our spec. Some can read past track 79, some can't. > >Sory to say that but you should have a standart drive!Now the industrie >produce ONLY drive with 'internal' motor speed control and ajustment! >So you have 300 RPM drive. >I cant speak for them! but if our software dont load, you have a VERY >bad >drive! We try with LARGE speed variation and it alway pickup the data >corectly. >No, people to custom track sizing! messing up with MFM coding!!! >Using table coding. Note my signature: I work at Commodore, and I'm the person responsible for the trackdisk device in 2.0 (which is rather more efficient than in 1.3 - most of the extra speed is that FS buffers no longer have to be in chip ram). We have a set of drive specs (as mentioned above). Drives may vary within those specs, and they do. >>Then they should do it. > >Well PIRACY is the key... From my part its a maybe! if more than 2 >people in >the ALL AMERICA want HD support, I might considered it... Why do you say 2? Go to comp.sys.amiga.games and search the archives (if you archive everything there - most places don't, we do). You'll find hundreds of people saying they want HD support. You're over-exaggerating your position. BTW, people are less likely to flame you if you avoid making inflammatory statements (statements that are likely and intended to annoy or anger people). It's like yelling at someone (face to face) that they're entirely wrong and don't have any idea what they're talking about. Rational, reasoned discussion (and disagreement with reasons, not absolute statements) works far better. >>things (I've gotten personal letters (snail-mail, no less) from people >like >>this. The company wouldn't even pay for RKMs, let alone joining the >>developer program.) > >Are we talking about quality amiga product? Well, when the amiga will >sell more then 20,000 copies world wide for the best game of the moment >they might be some consideration!? This person had done several "hits", and gets a salary instead of royalties. >Also! stunning has it can be! th WORST EVER amiga developers go to >DEVCON! perosnally receive the 2.0 doc from CBM president of the >concerned >contrie! etc etc... And only do PC port over the amiga that dont use >anything amiga at ALL! and trash the OS and rewrite BAD disk function >that cause return in LARGE number!.... That's the sort of obviously over-stated inflammatory comment I was describing above. I'll resist toasting you to a crisp (this time). Next time I may not be so nice. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (03/29/91)
In <mykes.0340@sega0.SF-Bay.ORG> mykes@sega0.SF-Bay.ORG (Mike Schwartz) writes: >What is the commodore approved way of doing this? Show us some code >that takes over all 512K on a 512K machine and returns back to the OS! You don't NEED all 512K, if you do the game correctly! >>> < floppy disk stuff > If it violates the hardware specs, it's JUNK. PERIOD! >>> < paraphrased SW hacks follow > > self modifying code, jump directly into ROM routines, > use the CPU for timing, use the upper 8 bits of addresses in RAM > and in registers for flags or other data Exactly, all of these thing break programs, and I've purchased games that do some or all of them. But I will never again buy from the publishers of any of those games, unless I get an ABSOLUTE, MONEY BACK guarantee that I will be able to use the game, on my system, in my way, up front, on the box, or demo'd in the store. I will buy games. BUT, I will NOT buy games that do not let me have a functional Amiga, while I play them. Mike Schwartz mentions EA. That is one company that I will NEVER buy from again, PERIOD. I have already kept my money in my pockets, rather than buy games I wanted, like "Starflight", because EA distributes games that DON'T work correctly, or are not well-ported to the Amiga. Dan Taylor * My opinions, not NCR's *
jesup@cbmvax.commodore.com (Randell Jesup) (03/29/91)
In article <1991Mar27.065420.16067@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > Nope not 5 years.A year and a half (but 4 people working on it). > Simply some people like chalenging project. If you're being a professional then this must be balanced against the expected revenue stream. > Also what do you do when you need tools that dont exist! > You create them.That take time if you want to do it right. > I would say if we ended up with a game like any other something > would have went wrong... One advantage of tools: you can use them again for the next game. > And what do you know about the project to think it could have been > done faster in C? Many studies have shown that programmers can write about the same number of lines of code per day no matter what the language (debugged lines). So in C it would probably be done sooner, though it would be larger or slower or both (but in many cases that doesn't matter, or you can mix them and do parts in asm). In some cases, pure ASM makes sense (and perhaps in your case). > But its true that was exesive and we will never do such project > complex project again! The only thing we got out of making such > a game is lost of money, but people told us Amiga games sold very > well and we beleived it... Thats why we thought it would pay to > investe so mutch in a game. You should have determined (a) how much work it would take to complete the project, (b) what it would sell for, (c) who would be likely to sell it for you, and how much in royalties you would get. You should have done all those things BEFORE getting far into the project. I vague "amiga games sell well" is a very chancy thing to invest 6 man-years in - a bad business decision. It may be that you should have cut down the project initially to 2 or 3 man-years (at least for the first version), and plan a sequel to be more complex if the first one succeeds. > And now I know why the majority are not interested in producing > quality amiga games. You need to be more than a hot programmer. You need to be a good designer (and they ARE separate skills, and very few people are excellent at both). You need to be a good businessman (or have one in the company). You may need a good artist (another skill). It sounds like you're missing the businessman (one reason why 9 out of 10 new businesses fail in their fist 5 years). I don't know about the others without seeing your game. I advise you go to the next Computer Game Design Conference (one just ended). They're held in (I think) San Jose each year, sponsered/started by the Journal of Computer Game Design (note: this is NOT a journal about game programming, but about game design - what the game _is_, not how it's done - Lemmings does very well in the design department). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (03/29/91)
In article <mykes.0396@sega0.SF-Bay.ORG> mykes@sega0.SF-Bay.ORG (Mike Schwartz) writes: >If you have 4 drives, >trackdisk.device eats up 40K. The trackdisk.device routines do not >use the DSKSYNC capabilities of the drive. Custom loaders can improve >performance by avoiding extra disk revolutions (this is done by timing >when you write to the disk in the first place). Actually, trackdisk uses more like 20K/drive (though that includes the filesystem, which isn't an issue for a bootblock game). The 2.0 trackdisk does use WORDSYNC/DSKSYNC. It helps, but it's an incremental improvement, not an order of magnitude one. Trackdisk doesn't wait for disk revolutions, it starts dmaing immediately (under 1.3) or when a sync is seen (under 2.0). Only if you need to use part of the data before you've had time to load it all in would aligning the track skews make sense. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
DXB132@psuvm.psu.edu (03/29/91)
In article <mykes.0470@amiga0.SF-Bay.ORG>, mykes@amiga0.SF-Bay.ORG (Mike Schwartz) says: >I have been lobbying Commodore to solve the problem. The problem is not with >the developers, but with the OS. What I suggest CBM does is to provide entry >points in Exec for software that takes over the machine to access both the >floppy drives and the hard disks. It is easy enough for them to do for 2.0 >before it goes to ROM. It should be noted that hard drive controller firmware is almost always resident in RAM, so you can't run out of ROMs directly. (This does not make it impossible, of course). The other thing is, normal drivers depend HEAVILY on the operating system. But you're right, C= could put the right hooks in there. (Not in time for 2.0 however). An alternative, maybe better, solution is to use the AmaxII driver set. Remember, AmaxII takes over the system just like nasty games. The AmaxII drivers provide the basic functionality you need without using the operating system. (It is possible that they may use the Mac OS, but in reality they don't). The drivers are self contained and position independent. (PC relative). Well, maybe they need a little glue code, I haven't really figured them out. -- Dan Babcock
jesup@cbmvax.commodore.com (Randell Jesup) (03/29/91)
In article <mykes.0470@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >I have been lobbying Commodore to solve the problem. The problem is not with >the developers, but with the OS. What I suggest CBM does is to provide entry >points in Exec for software that takes over the machine to access both the >floppy drives and the hard disks. It is easy enough for them to do for 2.0 >before it goes to ROM. > >The problem with hard disk support is that it REQUIRES the OS. Since all hard >disk controllers have ROM on them, the controllers could easily provide the software >routines needed to directly access the hard disk. Commodore should provide routines >in Exec that allow AmigaDos access to the hard disk through this mechanism. "easily"???? Their drivers depend HEAVILY on the system being fully up and available. For example, an A590 with SCSI and IDE(xt) drives has 3 tasks running, passing messages back and forth. Rewriting that to not use exec would require taking one of our (few, and VERY busy) programmers and having him devote 3-6 months to it (plus QA time, etc). You think every 3rd-party is going to spend that sort of money? ($20-50,000, depending on overhead, programmer experience, how long it takes.) And we haven't even discussed filesystems. being able to read/write the disk doesn't help, you need to read/write files on the disk. This means we'd have to rewrite the filesystem to work in this funny mode. This might be completed in 3-6 months (assuming we had a spare programmer (the current FS programmer is busy with another long-term project), but would require a LOT of QA time, and would require 15-25K of rom. We're tight enough that we fight for 1K. > Single >tasking computers can do it, so can the Amiga. There is no need for Exec or AmigaDOS >to be running to read the data from the drives. If Commodore provides this support, >we will all see more HD Installable games, especially those that take over the machine. Said single-tasking computers either don't have an OS, only a program loader (MSDOS), so it's already done, or they only support one filesystem and one drive interface (Mac) - and do people really take over the Mac and then access the harddrives? I assume the ST is similar to one or both of those. Just because you ask for it doesn't mean it feasible, practical or sensible. The amiga does have an OS, and as the line changes over the coming years, using the OS will help insulate you from hardware changes. It is not a game machine - if it was, there'd be no rom, no disk drive (cartridge), and maybe no keyboard. It's a computer that happens to also be able to run really good games. We won't cripple our future and hamstring our OS just for games that take over the machine. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
hbrinch@icoast.UUCP (Henrik Brinch) (03/29/91)
I'm getting fet up with these discussions about which language is best,
how to make the program best etc.
Some applications IS best for assembler and others would be insane to
program in it! The fact is what the individual programmer likes best,
a high-performance program with a long development time contra the
not-so-high-performance program with a short development time!
Some times it is also VERY clever to mix ie. C with ASM / ASM with C!
If the individual programmer doesn't want to make use of the systems
libraries then it is his choice, _BUT_ he MUST follow the Commodore
directions for legal code! That is the major problem with all hardware-
hackers, using processor pause's and sometimes priviliged instructions
etc. which only will work on one type of processor.
About harddisk installable games, you have to consider the PIRACY problem
it might be hard for you american people to see the problem, but for
the european people this is a HUGE problem. The european people has
ABSOLUTELY _NO_ respect for copyright on computer software (lack of moral!).
What can be done to prevent this - Well, PROTECTION is the only answer
(lower prices is just a bad excuse!). How can this protection be done?
By disk protection or password protection, what will you prefer?
I say neither of them... but you have to choose. Disk protection is
harder to remove and the only disadvantge is that it can't be installed
on harddisk, where a password protection will annoy you EVERY time you
use the program. The choice is yours! Another way is to register the
users of the program, but that's not a very safe solution.
From the user's point of view protection is really a pain in the *ss
but from the publisher/programmer there's no other way around it to
survive in this hard business.
For example look at "Dragon's Lair" it sold app. 60,000 copies...why?
Because it took the crackers 3 months to make a copy!
My point of view is : Games are not for hd's, BUT all other utilities
are harddisk stuff and MUST be installable.
Games usually kills the system (99.9%) so the programmers can use 500K
instead of 300K which again means better games. When killing the system
how would you access a harddisk? Using scsi.device? hahaha Forget about
that. All programs should be made keeping the system alive, again meaning
that it shouldn't be any problem to install it on harddrives.
I've made a commercial program myself, even WITHOUT protection, but that
program is in the educational part so the piracy problem isn't a problem.
The real problem is the block-busters which will be pirated and the
publisher/programmer will claim that they've lost several thousands of
dollars.... is this true? The people who pirate will they ever buy an
original? Perhaps not, and as I stated earlier the high software prices
is just a bad excuse, on the other hand if the prices is the problem
why even bother to buy a computer when you can't afford the software?
(BTW: In the reviews of my program, it was mentioned as a plus that there
wasn't any protection at all.... who knows maybe all the fun in copying
a non-protected program is gone, it's always funnier doing what's illegal
(common knowledge?)).
SOLUTION???? The software companies could make somekind of keydisk system
where you have to have inserted the original disk in the drive.
Face the facts : The world will always be full of pirates, and ALWAYS
full of protections you'll just have to live with them or boykot those
programs with protections.
I don't like reading about other programmers claiming to be the best,
"oh I've been xx years in business, with xx titles on the market"
BVADR safe us for that kind of crap and try to argument as adults instead!
I do hope this discussion is soon out of life!
Flame me if you want because I just loooove to be flamed! ;-)
Sincerely,
InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch
Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3
____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23
/ \/ \ Denmark \ "C is SILVER - But ASM is GOLD"mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (03/29/91)
In article <1991Mar28.201840.5130@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: > > How about a list of games each author in this "discussion" has done? >Then not only could we hear objective arguements, but WE as the >"listening public" make a subjective decsion on the quality of the >games. As long as most people don't hold a disk's protection scheme >against the author(s), since it is often done by the publishing house >(ie. Psygnosis, Electronic Arts etc...) > My Amiga credits: Budokan, Beyond Dark Castle, and Dark Castle. Dark Castle and Beyond Dark Castle were specifically designed to work for both the Amiga and the ST (boo) so they were done in 16 colors (for compatibility). BDC takes every advantage of what the Amiga can do for that game. I also did Dick Tracy on the Genesis. I am now doing a CDTV version of an existing Amiga game (more on this when it is done). I also reverse engineered the Genesis for EA. I did all of this (except for Dark Castle) in the last two years. I must also point out (for both Mike's sake and mine) that to truly judge a port, you need to judge it against the original version as well as how well it turned out on the Amiga. I can tell you that Dark Castle was a smash hit on the Mac, as was Crystal Quest (Mike's latest work). Budokan was rated by AmigaWorld as the 17th best game of the year last year. Dark Castle was nominated (among 200+ entries) for best port of the year in 1986 by the SPA (Software Publisher's Association) and finished in the top 7 (DeskView 2.0 on the PC, a windowed operating system, won). Dark Castle also was given the best possible review in AmigaWorld. I must also point out that Dark Castle was my first Amiga game, and I wouldn't rate the game very high by today's Amiga standards. >-- > adam hill -- hill@evax.uta.edu ASOCC - University of Texas at UTA > I programmed for three days Make Up Your Own Mind.. AMIGA! > And heard no human voices. Amiga... Multimedia NOW! > But the hard disk sang. - TZoP Born To Run SVR4 -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (03/29/91)
> >>Well PIRACY is the key... From my part its a maybe! if more than 2 >>people in >>the ALL AMERICA want HD support, I might considered it... Hey, add me to the list. If your game wont install on my hard disk, you wont sell it, at least to me! -mark= +--------+ ================================================== | \/ | Mark D. Manes "Mr. AmigaVision, The 32 bit guy" | /\ \/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ==================================================
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (03/30/91)
From article <mykes.0470@amiga0.SF-Bay.ORG>, by mykes@amiga0.SF-Bay.ORG (Mike Schwartz): > I have been lobbying Commodore to solve the problem. The problem is not with > the developers, but with the OS. What I suggest CBM does is to provide entry > points in Exec for software that takes over the machine to access both the > floppy drives and the hard disks. It is easy enough for them to do for 2.0 > before it goes to ROM. Except that everybody's hard disk device drivers require that Exec be up and running. They simply WILL NOT WORK unless Exec is up and running, because they depend on the interrupt system, the message passing system and the ability to run as a separate task. > The problem with hard disk support is that it REQUIRES the OS. Since all hard > disk controllers have ROM on them, the controllers could easily provide the software > routines needed to directly access the hard disk. Commodore should provide routines > in Exec that allow AmigaDos access to the hard disk through this mechanism. Single Excuse me, but this shows extreme ignorance of how the internals of the OS work. The actual dos.library was designed around the message-passing system... calls like Read() and Write() do not actually exist, all that happens is that the dos.library wraps up the request into a message packet and ships it off to the appropriate filesystem handler for the device in question. IT CANNOT WORK IF EXEC IS BOMBED!!! Period! The design of dos.library and the filesystem handlers is built around the message passing system, and you'd have to re-write them from scratch to make them work in a single-tasking non-Exec mode. It's like taking a Toyota Van, and trying to modify it to be a Toyota MR-2 sports car... you simply cannot do it. The beasts are too different. You'd have to re-do it from scratch (like Toyota did). So far, we've established that a) you don't know how AmigaDOS works, b) you haven't read the DevCon notes, especially the ones on how to hose the system such that it'd be recoverable, c)... do you even own a copy of the Rom Kernal manuals? You may be a great games programmer, but I get the impression that you don't know a whole lot about the Amiga's OS besides how to hose it. Times when you've said things like, "Exec needs 2K stacks minimum per task" are perfect proof of that... Exec *DOES* need more stack than your program needs for its own purposes, but that's only because when task switch time comes around your task's registers, 68010/68020 processor state, etc., are shoved onto the local stack. That data has to be stored *SOMEWHERE*, and if it's not stored onto the stack, it'll have to be stored in the task control structure somewhere. And 2K is a gross overestimate. -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg Looking for a job... tips, leads appreciated... inquire within...
schweige@aldebaran.cs.nps.navy.mil (Jeffrey M. Schweiger) (03/30/91)
In article <mykes.0594@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: |In article <1991Mar28.201840.5130@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: |> |> How about a list of games each author in this "discussion" has done? |>Then not only could we hear objective arguements, but WE as the |>"listening public" make a subjective decsion on the quality of the |>games. As long as most people don't hold a disk's protection scheme |>against the author(s), since it is often done by the publishing house |>(ie. Psygnosis, Electronic Arts etc...) |> | |My Amiga credits: Budokan, Beyond Dark Castle, and Dark Castle. Dark Castle |and Beyond Dark Castle were specifically designed to work for both the Amiga |and the ST (boo) so they were done in 16 colors (for compatibility). BDC |takes every advantage of what the Amiga can do for that game. I also did |Dick Tracy on the Genesis. I am now doing a CDTV version of an existing |Amiga game (more on this when it is done). I also reverse engineered the |Genesis for EA. I did all of this (except for Dark Castle) in the last |two years. | |I must also point out (for both Mike's sake and mine) that to truly judge |a port, you need to judge it against the original version as well as how |well it turned out on the Amiga. I can tell you that Dark Castle was a |smash hit on the Mac, as was Crystal Quest (Mike's latest work). I've seen postings from both Mike Farren and Mike Schwartz regarding games that they have written. I don't believe that I've seen a similar posting from Mr. Schaem, who started this entire thread of postings off. I, and I believe others of this group's readership might like to see something of the experience that Mr. Schaem claims to have, to help judge the credibility of the discussion. After generating, and then feeding the discussion, he seems to have dropped out. Jeff Schweiger -- ******************************************************************************* Jeff Schweiger Standard Disclaimer CompuServe: 74236,1645 Internet (Milnet): schweige@taurus.cs.nps.navy.mil *******************************************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (03/30/91)
In article <20198@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <mykes.0470@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>I have been lobbying Commodore to solve the problem. The problem is not with >>the developers, but with the OS. What I suggest CBM does is to provide entry >>points in Exec for software that takes over the machine to access both the >>floppy drives and the hard disks. It is easy enough for them to do for 2.0 >>before it goes to ROM. >> >>The problem with hard disk support is that it REQUIRES the OS. Since all hard >>disk controllers have ROM on them, the controllers could easily provide the software >>routines needed to directly access the hard disk. Commodore should provide routines >>in Exec that allow AmigaDos access to the hard disk through this mechanism. > > "easily"???? Their drivers depend HEAVILY on the system being >fully up and available. For example, an A590 with SCSI and IDE(xt) drives >has 3 tasks running, passing messages back and forth. Rewriting that >to not use exec would require taking one of our (few, and VERY busy) >programmers and having him devote 3-6 months to it (plus QA time, etc). >You think every 3rd-party is going to spend that sort of money? ($20-50,000, >depending on overhead, programmer experience, how long it takes.) > I programmed a custom 68000 box with a SCSI interface on it. The interface is trivial to write a driver for. All the manufacturers need to provide is the abililty for the proposed new ROM routines to read/write sectors. It doesn't require multitaskin or any OS to read/write sectors from the hard disk. Yes, GVP and other manufacturers are going to have to put extra code in their ROMs to support this simplistic form of access. My GVP manual describes all of the routines that their harddisk.device provides. All they need to do is to make the lowest level routines of that device public. You are exaggerating the requirements. At some point in every disk device (floppy or hard disk) you have to read and write sectors. This is the only capability that is needed. > And we haven't even discussed filesystems. being able to read/write >the disk doesn't help, you need to read/write files on the disk. This means >we'd have to rewrite the filesystem to work in this funny mode. This might >be completed in 3-6 months (assuming we had a spare programmer (the current >FS programmer is busy with another long-term project), but would require a >LOT of QA time, and would require 15-25K of rom. We're tight enough that we >fight for 1K. > You published source code in 'C' in AmigaMail that parses AmigaDos sectors on disk. It did not look like 25K of code. You are going to need the "takeover" programs to provide you with RAM buffer addresses to read the sectors into. If worse came to worse, I would be happy to call a routine in the ROM that would decompress the appropriate routines into RAM somewhere. You can save space that way. By the way, how much of the ROM is still in 'C'? If it weren't in 'C', you would save lots of K. >> Single >>tasking computers can do it, so can the Amiga. There is no need for Exec or AmigaDOS >>to be running to read the data from the drives. If Commodore provides this support, >>we will all see more HD Installable games, especially those that take over the machine. > > Said single-tasking computers either don't have an OS, only a program >loader (MSDOS), so it's already done, or they only support one filesystem >and one drive interface (Mac) - and do people really take over the Mac and >then access the harddrives? I assume the ST is similar to one or both of >those. > Atari publishes all the technical information required to access their hard disks through their DMA controller (which is built in to every ST). Single tasking computers (i.e. PCs) support a wide variety of hard disks/controllers with little effort. All we need is the ability to OPEN/READ/WRITE/CLOSE files on hard disk. We don't need multiple tasks to be able to access the files at the same time. We don't need Locks. You don't need DosPackets or any of the rest of the "junk" that the OS demands (and rightly so). Here is a simple explanation of the process of using hard disk without the OS: 1) Amiga boots, hard disk autoconfigs, Exec finds address of low level access routines on controller card and stores the addresses in ExecBase variables. 2) Someone loads my game (either from bootsector on floppy or by ICON or CLI). 3) My program looks at ExecBase to find the address of the low-level routines, plus the AmigaDos parser routines (well known locations). I can then take over whatever I want. 4) When I want to use hard disk, I call the Exec routine to decompress the rest of the hard disk access code into RAM. 5) I can then call Open() to open an AmigaDos file (who cares about other file systems). I will tell your routines where the controller's ROM routines are located (I saved them before I took over). 6) The routines in RAM call the low-level hard disk access routines provided by the controller to read in the ROOT block and can then locate the AmigaDos directory structures and ultimately the sectors on disk where the requested file resides. 7) When I call Read(), you read the appropriate sector(s) into the buffers I ask for. > Just because you ask for it doesn't mean it feasible, practical or >sensible. The amiga does have an OS, and as the line changes over the coming >years, using the OS will help insulate you from hardware changes. It is not >a game machine - if it was, there'd be no rom, no disk drive (cartridge), and >maybe no keyboard. It's a computer that happens to also be able to run >really good games. We won't cripple our future and hamstring our OS just >for games that take over the machine. > This illustrates exactly what the rest of the industry says about Commodore. The company comes across as not knowing what kind of machine they have. On one hand, you have the Amiga 500 which IS a game machine and is NOT much more useful for business/workstation uses than the C64 is. And on the other hand, you have the A2000+ class machines which are what you describe. Which of your machines are selling? Even if CBM stops selling the A500, 3rd parties will support it for 3-5 years more. People are still making C64 products. Compare the A500 with the lowest-end Mac. The classic has the ability to run a significant part of the business applications (it has 1Meg of RAM and separate memory for screen). The A500 has <400K with the OS running, and then the applications need memory for screens/windows/layers/messages and all the rest of the dynamic memory allocation that the OS does. Can you plug a video toaster into a stock A500? Can you run a complex application like Sculpt 4d? Can you run CygnusEd and edit a file > 200K? I submit that you won't be crippling your OS by adding the additional functionality of hard disk access. You will only be making all these screamers on the net happy because software written for the A500 will support more features of the (far fewer) workstation class machines. I don't see how this suggestion cripple's your future or Hamstring your OS. I see little added engineering cost involved for you and your 3rd party hard disk manufacturers. Just think of how well AMax would work if they had access to the low level drivers. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >Thus spake the Master Ninjei: "To program a million-line operating system >is easy, to change a man's temperament is more difficult." >(From "The Zen of Programming") ;-) -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (03/30/91)
In article <20198@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Just because you ask for it doesn't mean it feasible, practical or >sensible. The amiga does have an OS, and as the line changes over the coming >years, using the OS will help insulate you from hardware changes. It is not >a game machine - if it was, there'd be no rom, no disk drive (cartridge), and >maybe no keyboard. It's a computer that happens to also be able to run >really good games. We won't cripple our future and hamstring our OS just >for games that take over the machine. > Is the C64 a game machine? Yes, people do/did use it for business applications, but there is no doubt that it was used almost exclusively for game playing. The C64 also has an OS - called Basic, and just like the Amiga OS, game programmers didn't use it. The A500 is just as much of a game machine as the C64. I'm sure you realize that the vast majority of Amiga owners (those who one A500s) just stick in a game disk and reboot and could care less about the OS. They just want good games. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >Thus spake the Master Ninjei: "To program a million-line operating system >is easy, to change a man's temperament is more difficult." >(From "The Zen of Programming") ;-) -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (03/30/91)
In article <880@cns.SanDiego.NCR.COM> dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) writes: >I will buy games. BUT, I will NOT buy games that do not let me have a >functional Amiga, while I play them. Mike Schwartz mentions EA. That >is one company that I will NEVER buy from again, PERIOD. I have already >kept my money in my pockets, rather than buy games I wanted, like >"Starflight", because EA distributes games that DON'T work correctly, or >are not well-ported to the Amiga. > >Dan Taylor >* My opinions, not NCR's * I worked for EA two times. The first time, they were advertising that they stand behind the Amiga. I argued with my boss one time that they weren't doing much for the machine by porting C64 stuff to it. They would fund a PC original for years, but wouldn't do anything custom for the Amiga beyond Return from Atlantis and DPaint. They stand so far behind the Amiga that you can see them as a dot on the horizon :) -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/31/91)
In article <20198@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <mykes.0470@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>I have been lobbying Commodore to solve the problem. The problem is not with >>the developers, but with the OS. What I suggest CBM does is to provide entry >>points in Exec for software that takes over the machine to access both the >>floppy drives and the hard disks. It is easy enough for them to do for 2.0 >>before it goes to ROM. This whole argument is dumb. You can EASILY write games that run under the OS. What do you do? you simply lockout intuition, setting the input.device priority to -60 will do the trick nicely. Suddenly, the OS isn't using jack of the CPU and your game can set up its own screens via the graphics.library and manipulate screens directly, even use the blitter, copper, and other OS resources. graphics.library is still fully available. The nice thing about the above method is that you can still use intuition if you need to, for initial setup for example... to open up the screen and set up the initial layers (if you intend to use layers). But during game play the whole business gets 0 cpu. > "easily"???? Their drivers depend HEAVILY on the system being >fully up and available. For example, an A590 with SCSI and IDE(xt) drives >has 3 tasks running, passing messages back and forth. Rewriting that >to not use exec would require taking one of our (few, and VERY busy) >programmers and having him devote 3-6 months to it (plus QA time, etc). >You think every 3rd-party is going to spend that sort of money? ($20-50,000, >depending on overhead, programmer experience, how long it takes.) > > And we haven't even discussed filesystems. being able to read/write >the disk doesn't help, you need to read/write files on the disk. This means >we'd have to rewrite the filesystem to work in this funny mode. This might >be completed in 3-6 months (assuming we had a spare programmer (the current >FS programmer is busy with another long-term project), but would require a >LOT of QA time, and would require 15-25K of rom. We're tight enough that we >fight for 1K. > > Just because you ask for it doesn't mean it feasible, practical or >sensible. The amiga does have an OS, and as the line changes over the coming >years, using the OS will help insulate you from hardware changes. It is not >a game machine - if it was, there'd be no rom, no disk drive (cartridge), and >maybe no keyboard. It's a computer that happens to also be able to run >really good games. We won't cripple our future and hamstring our OS just >for games that take over the machine. > >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >Thus spake the Master Ninjei: "To program a million-line operating system >is easy, to change a man's temperament is more difficult." >(From "The Zen of Programming") ;-) I agree with Randell completely, all these idiot game writers insist on taking over the machine when, in fact, they do not have to. My solution alone (simply reduce the task priority of CPU hogging tasks) guarentees a game the CPU when it needs it, yet still allows said game to use DOS & intuition when/if it needs to. It just isn't a problem. This goes down with idiots who make direct ROM calls, assume absolute RAM locations (other than 4), and design hardware without using bypass capacitors :-) -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
DXB132@psuvm.psu.edu (03/31/91)
In article <00670283123@elgamy.RAIDERNET.COM>, elg@elgamy.RAIDERNET.COM (Eric Lee Green) says: >to hose it. Times when you've said things like, "Exec needs 2K stacks >minimum per task" are perfect proof of that... Exec *DOES* need more stack >than your program needs for its own purposes, but that's only because when >task switch time comes around your task's registers, 68010/68020 processor >state, etc., are shoved onto the local stack. That data has to be stored >*SOMEWHERE*, and if it's not stored onto the stack, it'll have to be stored >in the task control structure somewhere. And 2K is a gross overestimate. If you make ANY operating system calls at all, you'd be a fool to allocate less than 4K for a stack. Otherwise you're gauarenteed to crash under 2.0, 3.0, 4.0 or whatever C= comes up with. (This is just my opinion, OK ?) -- Dan Babcock
mt87692@cs.tut.fi (MIT) (03/31/91)
Hello,
Since I'm again (*sigh*) one reason (I posted arcticle considering
why Farren plays Lemmings after flaming it) for this flood of letters
I would like to point out my opinions on matter of games (I spend most
of my time playing games). I refer to programs in this arcticle meaning
both games and utilities.
DISCLAIMER: I speak for myself. I'm intending to earn my living with
programming (games if I can live with doing only games) but so far I
have made only some utilities and half-finished products.
Every program must work on all existing Amiga platforms matching or
overtaking the requirements. I say existing because you can't test
your programs on non-existing platform. Some programs might need extra
memory, HD or new OS, but those programs can have marketing problems.
There is no use using assembler if speed and size are not essential
but on the other hand everything should not be made with higher
language either. It does not actually matter if you are using the
hardware directly or using the system but for some things system is
not fast enough. There are some drawbacks using direct hardware
control which I noticed when I tried to run my programs for the first
time on a productivity mode WB on A3000:-( Especially amiga has much
special hardware which makes it easy to make fast programs using the
custom hardware, there is no use copying the scrolling area around
because there are bitplanepointers which can be used for scrolling and
only a small amount of data must be drawn. There is no use making long
processor loops for copying since there is a blitter. Actually
carefull planning is the most importang thing in the coding, not
language or hardware/OS selection.
Every program can be put on the HD since "everybody" uses HD's when
they are writing and testing programs. Basically there are some
reasons for the finished programs not to be HD installable: 1)
Protection must be manual protection for hd-games which leads to
manual xeroxing, 2) Because custom floppy-loaders are faster and more
data can be but on one disk so it's easier to sell for people with
inexpensive platform, 3) OS requires memory so some compromises much
be made in order to make it work on 512K of memory. The third reason
is perhaps the most diffucult one because it greatly affects the
outlook of a program.
Multitasking is a whole different thing. Multitasking eats resources,
processor speed and memory which affects as jerky animation and less
"features". On the other hand it gives the user a change of what he
wants to do in the same time. Multitasking can not be used for fast
arcade programs because they lost the playbility if the movement is
jerky. Strategy type games can easily multitask. Every program is
restoring the OS and can be exited in the developing stages so every
program can easily made exitable if there is enought memory. Perhaps
restoring the multitasking in pause mode is the best solution for
arcade type games.
All available memory must be used if user wants to give all memory to
one program.
CONCLUSION: All programs can be made exitable and hd-installable if
there is enough interest. Multitasking can be sometimes made during
the actuall playing session.
=> The reason for non-exitable and non-hd-installable programs is not the
skills of a programmer but rather it is the marketing.
For this reason I'd say Farren should send his letter to the
distributor too (In this case Psygnosis).
MIT
--
/// AMIGA
/// Pal A2k rev6.2, Kick1.3, 1MB chip, 8M fast
\\\ /// 2x3.5"floppy, Supra WS & Q105S, 2090A & 40M HD.
\\X// MITjesup@cbmvax.commodore.com (Randell Jesup) (03/31/91)
In article <mykes.0692@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <20198@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> "easily"???? Their drivers depend HEAVILY on the system being >>fully up and available. For example, an A590 with SCSI and IDE(xt) drives >>has 3 tasks running, passing messages back and forth. Rewriting that >>to not use exec would require taking one of our (few, and VERY busy) >>programmers and having him devote 3-6 months to it (plus QA time, etc). >>You think every 3rd-party is going to spend that sort of money? ($20-50,000, >>depending on overhead, programmer experience, how long it takes.) > >I programmed a custom 68000 box with a SCSI interface on it. The interface >is trivial to write a driver for. Not "trivial" if you want to handle all the tricky edge-cases (like the reselection issues, where what the chip does varies by chip rev, and the state of the chip is undefined). > All the manufacturers need to provide is >the abililty for the proposed new ROM routines to read/write sectors. It doesn't >require multitaskin or any OS to read/write sectors from the hard disk. Yes, >GVP and other manufacturers are going to have to put extra code in their ROMs >to support this simplistic form of access. My GVP manual describes all of the >routines that their harddisk.device provides. All they need to do is to make >the lowest level routines of that device public. You are exaggerating the >requirements. At some point in every disk device (floppy or hard disk) you >have to read and write sectors. This is the only capability that is needed. Sure. And they all need interrupt handlers, and are often coded to require memory allocations, multiple tasks (the A590/A2091/A3000 driver consists of 2 or 3 tasks (depending)), lots of exec functions, etc. They would have to rewrite their driver (not from scratch, but it would require an engineer for several months at a guess to get it done, tested, and stable). Then there's QA issues, and field upgrades, etc. >> And we haven't even discussed filesystems. being able to read/write >>the disk doesn't help, you need to read/write files on the disk. This means >>we'd have to rewrite the filesystem to work in this funny mode. This might >>be completed in 3-6 months (assuming we had a spare programmer (the current >>FS programmer is busy with another long-term project), but would require a >>LOT of QA time, and would require 15-25K of rom. We're tight enough that we >>fight for 1K. > >You published source code in 'C' in AmigaMail that parses AmigaDos sectors on >disk. It did not look like 25K of code. You are going to need the "takeover" >programs to provide you with RAM buffer addresses to read the sectors into. >If worse came to worse, I would be happy to call a routine in the ROM that would >decompress the appropriate routines into RAM somewhere. You can save space that >way. Parsing sectors on disk is nothing like what a filesystem does. You aren't listening to what I'm saying. (And I was being optimistic on the time required.) >By the way, how much of the ROM is still in 'C'? If it weren't in 'C', you would >save lots of K. Maybe 60% (rough guess). So, you magically can provide an extra 10 top-notch programmers 2-3 years ago, plus another 10 or 20 QA people a year or two ago? Sure, some stuff gets downcoded when we need the space or speed. Most of the low-level stuff has been in ASM since the beginning. Yes, there's space we could get back. In places where it makes sense, we do. Remember, we have to maintain this code (unlike most game code, which is mainly write- once - often even sequels are 100% new code). For example, most of intuition and almost all of gadtools is in C. This will be VERY useful when 2.2 or 3.0 or whatever comes along. Also, every time the compilers get better we benefit. 5.10a saved us many K over greenhills in 2.0 (some things are still in greenhills, like intuition, because the risk and time in moving it over was greater than the benefit). >> Said single-tasking computers either don't have an OS, only a program >>loader (MSDOS), so it's already done, or they only support one filesystem >>and one drive interface (Mac) - and do people really take over the Mac and >>then access the harddrives? I assume the ST is similar to one or both of >>those. > >Atari publishes all the technical information required to access their hard disks >through their DMA controller (which is built in to every ST). 1) ST is single-tasking, 2) there is only 1 (normal) interface, as is expected in an unexpandable machine. It hits both my points. >Single tasking computers (i.e. PCs) support a wide variety of hard disks/controllers >with little effort. All we need is the ability to OPEN/READ/WRITE/CLOSE files >on hard disk. We don't need multiple tasks to be able to access the files at >the same time. We don't need Locks. You don't need DosPackets or any of the >rest of the "junk" that the OS demands (and rightly so). Here is a simple >explanation of the process of using hard disk without the OS: The more "junk" you throw out the bigger the job of writing a single- tasking FS is. The PC clones support HDs via drivers that emulate old st506 drive controllers. The routines are callable in "take-over" games since there is no such thing on the PC as NOT taking over. MSDOS is a program- loader, not an OS. >5) I can then call Open() to open an AmigaDos file (who cares about other > file systems). I will tell your routines where the controller's ROM > routines are located (I saved them before I took over). I care. More and more users will care. Note that we now support booting off ANY fifesystem (via rigid disk blocks). You can boot off an MSDOS filesystem if you want, of a Unix Berkeley FFS, or a Sys V UFS, etc, etc. You can even boot off a network filesystem (certainly you might want to save your high score on the server so everyone can have a common high-score file - I do this now in NetHack.) >Compare the A500 with the lowest-end Mac. The classic has the ability to run >a significant part of the business applications (it has 1Meg of RAM and separate >memory for screen). Oh boy, 21888 whole bytes. (And last I checked in the Apple docs, the screen memory comes out of your 1Meg.) And of course an a500 can have 1Meg EASILY, and CHEAPLY. Plus a 500 can be expanded (again, easily) to do most (though not quite all) things that higher-end amigas can do. Have you ever programmed games on a Mac? They're far more picky about people trying to take over machines than we are. >I submit that you won't be crippling your OS by adding the additional functionality >of hard disk access. You will only be making all these screamers on the net >happy because software written for the A500 will support more features of the >(far fewer) workstation class machines. I don't see how this suggestion cripple's >your future or Hamstring your OS. I see little added engineering cost involved >for you and your 3rd party hard disk manufacturers. If we added everything you want (and it's NOT by any means cheap - we could be talking many hundreds of thousands of dollars, and even then would only be available on machines with whatever the new version of the rom was) we'd be stuck trying to find ways to upgrade the hardware/software a bit down the road. It's bad enough as it is, this would make it much worse. Oh, and please tell us which part of the OS we should remove to fit your stuff in. One of the purposes of an OS is to insulate you from hardware differences. This is the sort of thing that killed the 64. There was NO way to upgrade the hardware without breaking 99% of the programs out there. You can't even change a byte or two in the rom safely. I've had enough. You're obviously interested in pure game machines, which the Amiga is not. Perhaps we'll build a pure game machine again someday (like the 64) where you can hack around to your hearts content. But it won't be an Amiga. Even CDTV has the ability to upgrade the hardware, and if you go around the back of the OS and program around the rules of accessing the hardware, you may well find yourself in trouble there too. The hardware can change, the software can change (it has flash-eproms). If you want to ask programming questions, fine. If you want to spout off about how wonderful taking over the machine is, do it elsewhere. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
jsmoller@jsmami.UUCP (Jesper Steen Moller) (04/01/91)
In article <91089.151122DXB132@psuvm.psu.edu>, DXB132@psuvm.psu.edu writes: > In article <00670283123@elgamy.RAIDERNET.COM>, elg@elgamy.RAIDERNET.COM (Eric > Lee Green) says: > > >to hose it. Times when you've said things like, "Exec needs 2K stacks > >minimum per task" are perfect proof of that... Exec *DOES* need more stack > >than your program needs for its own purposes, but that's only because when > >task switch time comes around your task's registers, 68010/68020 processor > >state, etc., are shoved onto the local stack. That data has to be stored > >*SOMEWHERE*, and if it's not stored onto the stack, it'll have to be stored > >in the task control structure somewhere. And 2K is a gross overestimate. > > If you make ANY operating system calls at all, you'd be a fool to > allocate less than 4K for a stack. Otherwise you're gauarenteed to crash > under 2.0, 3.0, 4.0 or whatever C= comes up with. (This is just my > opinion, OK ?) I just wrote a program that did major OS work (device I/O for instance) and it worked with 1800 bytes stack. I developed it under 2.0 and there it only needed 512 bytes, but when I tried it under 1.3 I had to use more. So I don't feel like a fool, I feel that I have shaved the stack size, but not too closely. The OS needs some stack but the most weight is on the algorithms - my program didn't quicksort a large array. I'd needed tons of stack for that. (This is my OS's opiniin and it's OK!) > -- Dan Babcock -- Jesper Steen Moeller -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/
hbrinch@icoast.UUCP (Henrik Brinch) (04/01/91)
In article <dillon.5753@overload.Berkeley.CA.US>, Matthew Dillon writes: > I agree with Randell completely, all these idiot game writers insist on > taking over the machine when, in fact, they do not have to. My solution > alone (simply reduce the task priority of CPU hogging tasks) guarentees > a game the CPU when it needs it, yet still allows said game to use > DOS & intuition when/if it needs to. > > It just isn't a problem. I tell you the problem. MEMORY - not everybody has 1Mb (or more) and killing the system will give you app. 200Kb more and the ability for more sophisticated diskloaders / protections. (Please don't flame me about this, I'm a system-programmer and wouldn't kill the system.... I'll do anything to keep that wonderfull system alive!). > This goes down with idiots who make direct ROM calls, assume absolute > RAM locations (other than 4), and design hardware without using bypass > capacitors :-) Hear hear, I thought the time about making direct ROM calls where over (at least I hoped it was!). I disagree with you about the absolute ram locations, if you shut down the system PERFECTLY (interrupts, tasks....EVERYTHING!) then any address from about $c0-$7ffff should be okay. BUT(!) if the system is partly alive NO absolute ram locations is allowed (I've learned that from hard experience!). > Matthew Dillon dillon@Overload.Berkeley.CA.US Best Regards, InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3 ____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23 / \/ \ Denmark \ "C is SILVER - But ASM is GOLD"
dfrancis@tronsbox.xei.com (Dennis Heffernan) (04/02/91)
I think the "bash the OS" forces need to get a clue. I don't honestly care how many moving objects you can cram on the screen, or whether or not the game has 245E+10 levels (which all look the same anyway). I DO care about the quality of the game play. Some of the best games I ever played were originally done on platforms like the C64 or even the Atari 2600. And no matter how much you gussied them up, they wouldn't be any better if ported to the Amiga. PIRATES, for instance, is one of my favorite games. I originally bought it for my 64, and enjoyed it enough that I bought the Amiga version when it came out. It's a perfect example of what an Amiga game should be, even if it only has two moving objects (most of the time) and no eurorock soundtrack. Looking over my collection, the games I've enjoyed the most are the ones with some kind of engaging plot, with lots of different things to do. ROCKET RANGER (my all-time fave, which I'm going to miss when I get a hard drive because anything that won't load on it is going out the window...), LAND OF THE RISING SUN, WINGS (hmm, lots of CinemaWare...), the AD&D games from SSI (though they're poorly implemented; there's no reason why they couldn't be as friendly as PIRATES), STAR CONTROL... That last one is the closest thing to a shoot'em up that I own for the Amy. It doesn't bash the machine, either. I don't personally know a single person who enjoys pure shoot-em-ups. I can't understand why anyone writes them any more. I haven't seen one in years that didn't look like every other one ever done. The same goes for climbing and jumping games- I've played SHADOW OF THE BEAST (on another machine, it won't run on mine...), and it's nothing but a hyperthyroid DONKEY KONG with an attitude. Yawn. The dinosaurs died so that the plastic it is encoded on could exist, and I'm hard-pressed to come up with a reason why. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "I don't understand why you make such a big deal out of everything...haven't you learned; if it's not happenning to me it's not important?" -Murphy Brown
dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (04/02/91)
In <mykes.0692@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >2) Someone loads my game (either from bootsector on floppy or by > ICON or CLI). >3) My program looks at ExecBase to find the address of the low-level routines, > plus the AmigaDos parser routines (well known locations). I can then > take over whatever I want. I, for one, do NOT want a game doing ANY low-level access to my hard disks. Given the almost TOTAL LACK of QA (that's QUALITY ASSURRANCE) by game programmers, and publishers, I'd expect to have to rebuild my disk after every gaming session. Whay about people who have multiple drives, or (like me) multiple controllers? How do you know which dirve/controller to access? What if I load the game into RAM: or RAD:? You REALLY don't understand the problem, which is what we've been saying, all along. Really, though, the point is that the Amiga IS multi-tasking. Those who have hard disks and extra RAM bought them to use. A game that takes away the ability to run other tasks simultaneously, has no place on an Amiga. Dan Taylor * My opinions, not NCR's *
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/02/91)
In article <18ead851.ARN0f31@icoast.UUCP> hbrinch@icoast.UUCP writes: > >I tell you the problem. MEMORY - not everybody has 1Mb (or more) and >killing the system will give you app. 200Kb more and the ability for more >sophisticated diskloaders / protections. >(Please don't flame me about this, I'm a system-programmer and wouldn't > kill the system.... I'll do anything to keep that wonderfull system alive!). Well, I will flame you about that ridiculous statistic of 200K! MAYBE, if you have a highres overscan WB, the screen will take up 100K+, but then the workbench screen can always be CLOSED! -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/02/91)
In article <1517@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > > I think the "bash the OS" forces need to get a clue. I don't honestly >care how many moving objects you can cram on the screen, or whether or not the >game has 245E+10 levels (which all look the same anyway). I DO care about the >quality of the game play. Some of the best games I ever played were originally >done on platforms like the C64 or even the Atari 2600. And no matter how much >you gussied them up, they wouldn't be any better if ported to the Amiga. > Agreed! Shadow of the Beast is a technically awesome game with great graphics. It is fun to wow friends with, and is fun to watch, for about 20 minutes. This is more true I guess of the out-and-out shoot-em-up which just isn't creative, but the graphics can really wowing. > PIRATES, for instance, is one of my favorite games. >It's a perfect example of what an Amiga game should be, >even if it only has two moving objects (most of the time) and no eurorock >soundtrack. > > Looking over my collection, the games I've enjoyed the most are the >ones with some kind of engaging plot, with lots of different things to do. >ROCKET RANGER (my all-time fave, which I'm going to miss when I get a hard >drive because anything that won't load on it is going out the window...), >LAND OF THE RISING SUN, WINGS (hmm, lots of CinemaWare...), Agreed. CinemaWare games weren't graphically miraculous, but they were still nice artwork, were interesting and had nice scene-dependent sound/music. They held my interest long enough to finish them. I believe that Rocket-Ranger is my all-time favorite game. And, BTW, there was no Euro-Rock music, but the music was catchy and exciting. I still remember the Rocket-Ranger music, it really got to me. Note that none of the games which are the most interesting use 60fps, and thus none of them really NEED to take the system over. How about Sierra On-Line? Yes, I know they are junk ports. But Space Quest I-III were damn funny, they were hard-drive installable, there was no copy-protection and multitasked just fine. BTW, Mike F., I don't think taking over the machine is the worst thing in the world, even if you can't restore to where you were. What I want in return is the ability to use my expanded memory to pre-store data, to use a second disk drive (for God's sake!) and, preferably, to use the HD. In pre-response to what Mike S. and Steven S. are going to reply (I think), you will get better sales from a game that has some thinking involved, rather than simple rapid-fire animation. Realistically, most people won't even think of buying those games. They will either pirate them or just not care. There are SO many of these basic simple games with neato graphics and absolutely nothing to keep you playing it. You mention that in 3 months all the old games are off the shelf and replaced. That may be true for the latest shoot-em-up, because it isn't going to keep people's attention, but I still see old CinemaWare games and games like Dungeon Master on store shelves. They sell anyway. I'm babbling, gotta stop doing this. 8-) >dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 >------------------------------------------------------------------------------ >"I don't understand why you make such a big deal out of everything...haven't >you learned; if it's not happenning to me it's not important?" -Murphy Brown -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
terminal@phoenix.pub.uu.oz.au (Bernard Leach) (04/02/91)
In <1998@aldebaran.cs.nps.navy.mil> schweige@aldebaran.cs.nps.navy.mil (Jeffrey M. Schweiger) writes: >Well, I, for one, like hard drive support. I also dislike copy protection, >custom operating systems, and lack of multi-tasking. Ok discopy protection I can understand but multi-tasking.. I fail to see how my poor old 68000 could keep up with a fastmoving game of Shadow of the Beast, downloading from the local BBS, and editing my latest school essay!! Not to mention the fact that *I* would have some trouble keeping up with that! Fair deal people! If you cant handle the time for a game to load, do you *really* have time to play the game at all? Sure some games are nice on the HD, Pirates is a good example, well not really because it *is* hd-installable, but if it werent that would be a hassle... but then the fact that it is and the fact that it does not take over the system indicates that *some* programmers do think about these things.. bernard.
hbrinch@icoast.UUCP (Henrik Brinch) (04/02/91)
In article <1991Apr2.002244.11549@cunixf.cc.columbia.edu>, Ethan Solomita writes: > In article <18ead851.ARN0f31@icoast.UUCP> hbrinch@icoast.UUCP writes: > > > >I tell you the problem. MEMORY - not everybody has 1Mb (or more) and > >killing the system will give you app. 200Kb more and the ability for more > >sophisticated diskloaders / protections. > >(Please don't flame me about this, I'm a system-programmer and wouldn't > > kill the system.... I'll do anything to keep that wonderfull system alive!). > > Well, I will flame you about that ridiculous statistic of > 200K! MAYBE, if you have a highres overscan WB, the screen will Excuse me, I said "app."! Okay, I probably mentioned a too large number BUT judge for yourself, you have from $c0-$7ffff (app. 524000 bytes) then break the CLI sequence and check your memory (AVAIL you know). You have the CLI/WB screen (app.(!!!!!) 80K) + the exec/dos system do I really have to tell you more? If it isn't 200K it's less, but not much less.... still enough memory for quite some game-effects (levels/sounds etc.). > take up 100K+, but then the workbench screen can always be > CLOSED! Why SHOULDN'T it be closed, I would say it's pretty strange to kill the system and leave the WB screen open ! > -- Ethan InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3 ____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23 / \/ \ Denmark \ "C is SILVER - But ASM is GOLD"
nj@magnolia.Berkeley.EDU (Narciso Jaramillo) (04/03/91)
Followups to comp.sys.amiga.advocacy. In article <1517@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >I don't personally know a single person who enjoys pure shoot-em-ups. >I can't understand why anyone writes them any more. I haven't seen one in years >that didn't look like every other one ever done. The same goes for climbing >and jumping games- I've played SHADOW OF THE BEAST (on another machine, it won't >run on mine...), and it's nothing but a hyperthyroid DONKEY KONG with an >attitude. Yawn. The dinosaurs died so that the plastic it is encoded on could >exist, and I'm hard-pressed to come up with a reason why. I'm beginning to think the problem is one of misplaced talent. Most of the arguments in favor of hardware hacking are ``Whizzy games sell well, and you have to hack the hardware to write whizzy games.'' I think the real reason is the other way around: Whizzy demos don't sell on their own. If the really talented hardware hackers could sell nifty-fast graphic demos on their own merits as pieces of art, then games designers could hire programmers who were less interested in creating art and more interested in writing playable games. Unfortunately, whizzy demos on the Amiga don't sell; their best hope is to get wide distribution on the bootblock of a pirated program, or to be released on BBSes or by FTP. So all these talented hacker/artists end up working for game companies, and you get games like Shadow of the Beast--people buy it because it's pretty, play it for awhile, then lose interest because it's not actually a good game. This is even more apparent for games like Lemmings or Beast II, where you have a long introductory animation that doesn't do anything but take up space on the disk. It's cute, but only the first time you see it. It does nothing to enhance gameplay. This is probably an indirect reason for rampant games piracy among people who can afford them--let's call them ``white-collar pirates.'' White-collar pirates probably don't feel that if they bought the game, they would actually play it long enough to justify the money they spent. They just want a copy so they can look at the pretty pictures for a few days. nj
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/03/91)
In article <18ead851.ARN0f31@icoast.UUCP> hbrinch@icoast.UUCP (Henrik Brinch) writes: >In article <dillon.5753@overload.Berkeley.CA.US>, Matthew Dillon writes: > >> I agree with Randell completely, all these idiot game writers insist on >> taking over the machine when, in fact, they do not have to. My solution >> alone (simply reduce the task priority of CPU hogging tasks) guarentees >> a game the CPU when it needs it, yet still allows said game to use >> DOS & intuition when/if it needs to. >> >> It just isn't a problem. > >I tell you the problem. MEMORY - not everybody has 1Mb (or more) and >killing the system will give you app. 200Kb more and the ability for more >sophisticated diskloaders / protections. Memory can indeed be considered a problem, but only for machines that don't have much of it. This is easily determined by AvailMem() and, frankly, if a game can allocate the memory it needs via AllocMem(), it should. A little cleverness, like NOT using an absolute origin, means the game will run that much better on even minimally expanded machines. >(Please don't flame me about this, I'm a system-programmer and wouldn't > kill the system.... I'll do anything to keep that wonderfull system alive!). No flame, it's a good arguing point, and clashes the philosophy of designing for a specific memory mind-set (so to speak), which is frankly a first rate way to program yourself into a corner, as has already been mentioned. >I disagree with you about the absolute ram locations, if you shut down the >system PERFECTLY (interrupts, tasks....EVERYTHING!) then any address from >about $c0-$7ffff should be okay. BUT(!) if the system is partly alive >NO absolute ram locations is allowed (I've learned that from hard experience!). > > >> Matthew Dillon dillon@Overload.Berkeley.CA.US It's too dangerous, just because it works NOW doesn't mean it will work later... at the very least one should AllocAbs() it to make sure it isn't being used, and what happens if you find that it *IS* being used? You can't run your game at all then. Any autoconfig board's driver can allocate memory anywhere, and it can occur before your game starts up, and it can be SENSITIVE to being ripped out from under it.. one cannot make the assumption that the memory is all free. One can't even assume he will be safe if he turns off all the interrupts! This is why so many games break when you, say, have a bridgeboard in your system (though not necessarily for the above stated possible scenerio). The funny thing is that it is so EASY to write relocatable code.. incredibly easy. I fail to understand why game programmers insist on assembling one big program in one shot to an absolute location when development goes much faster when you break it up into smaller modules that generate objects... so when you make a change you are changing only ONE SMALL object module and relinking instead of reassembling the whole thing. It took me about 2 hours to figure out the Amiga object file format, and only 5 minutes to understand the executable format. A game doesn't need to know anything beyond the executable format if it loads/relocs it itself, and even then it could be just as efficient to just use LoadSeg(), depending on your situation. Relocation information does not take that much space, especially when you use the small-data model (i.e. A4-relative). >Best Regards, > >InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch >Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3 >____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23 > / \/ \ Denmark \ "C is SILVER - But ASM is GOLD" -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
bairds@eecs.cs.pdx.edu (Shawn L. Baird) (04/03/91)
hbrinch@icoast.UUCP (Henrik Brinch) writes: >In article <1991Apr2.002244.11549@cunixf.cc.columbia.edu>, Ethan Solomita writes: >> take up 100K+, but then the workbench screen can always be >> CLOSED! >Why SHOULDN'T it be closed, I would say it's pretty strange to kill the >system and leave the WB screen open ! I think he was talking about the OS routine to close the Workbench screen. There is only one problem. An application can not count on the ability of the Workbench screen to be closed. If a CLI or other program is running on the workbench (that is, besides workbench itself) the Workbench screen will not close. Now granted, you could tell the user to go remove any offending programs, but is this really what you want to sell to a consumer? Your sales would probably drop because of the hassle everyone would have to go to just to run the damned thing. The OS itself eats up a lot more memory than just the workbench screen. Although, granted, it's pretty small considering what it does (mostly because a lot of it is in ROM). >> -- Ethan >InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch >Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3 >____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23 > / \/ \ Denmark \ "C is SILVER - But ASM is GOLD" --- Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD The above message is not licensed by AT&T, or at least, not yet.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/03/91)
In article <18ec731b.ARN0f5b@icoast.UUCP> hbrinch@icoast.UUCP writes: >In article <1991Apr2.002244.11549@cunixf.cc.columbia.edu>, Ethan Solomita writes: > >> In article <18ead851.ARN0f31@icoast.UUCP> hbrinch@icoast.UUCP writes: >> > >> >I tell you the problem. MEMORY - not everybody has 1Mb (or more) and >> >killing the system will give you app. 200Kb more and the ability for more >> >sophisticated diskloaders / protections. >> >(Please don't flame me about this, I'm a system-programmer and wouldn't >> > kill the system.... I'll do anything to keep that wonderfull system alive!). >> >> Well, I will flame you about that ridiculous statistic of >> 200K! MAYBE, if you have a highres overscan WB, the screen will > >Excuse me, I said "app."! Okay, I probably mentioned a too large number >BUT judge for yourself, you have from $c0-$7ffff (app. 524000 bytes) >then break the CLI sequence and check your memory (AVAIL you know). >You have the CLI/WB screen (app.(!!!!!) 80K) + the exec/dos system do I >really have to tell you more? >If it isn't 200K it's less, but not much less.... still enough memory for >quite some game-effects (levels/sounds etc.). > >> take up 100K+, but then the workbench screen can always be >> CLOSED! > >Why SHOULDN'T it be closed, I would say it's pretty strange to kill the >system and leave the WB screen open ! > Isn't that what I said? Of course you would close the scree, even applications programs kill the workbench screen. The screen itself takes up 32K, 64K if it is interlaced. From my experience the OS takes up about 80-100K of RAM, which is a lot less than 200K if you consider there are only 512K to take from. >> -- Ethan > >InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch >Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3 >____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23 > / \/ \ Denmark \ "C is SILVER - But ASM is GOLD" -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
jbickers@templar.actrix.gen.nz (John Bickers) (04/04/91)
Quoted from <1517@tronsbox.xei.com> by dfrancis@tronsbox.xei.com (Dennis Heffernan): > I don't personally know a single person who enjoys pure shoot-em-ups. I do. I particularly like Sidewinder - a lot of the other shoot-em- ups I've happened to see have been fairly dense. On the other hand, I still reckon the C=64 version of Elite is better than the Amiga one (relatively speaking), by a mile or two. > dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
greg@ccwf.cc.utexas.edu (Greg Harp) (04/04/91)
In article <2194@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >I think he was talking about the OS routine to close the Workbench screen. >There is only one problem. An application can not count on the ability of >the Workbench screen to be closed. If a CLI or other program is running on >the workbench (that is, besides workbench itself) the Workbench screen will >not close. Now granted, you could tell the user to go remove any offending >programs, but is this really what you want to sell to a consumer? Your >sales would probably drop because of the hassle everyone would have to go >to just to run the damned thing. You'd rather sell the consumer a program that wipes out the OS than one that required the user to shut down a program or two before running, but allowed them to return to a functioning OS after the game had ended (w/o rebooting)? Somehow I'd figure that most programs that were left running (other than VirusX or the like) were there getting _work_ done. Killing the OS can have catastrophic results in such a case. Most users won't think about such a thing until they get bitten... I wonder whose sales would drop because their OS-killing program stopped some other program that happened to be in the middle of writing to a disk. At least if you restore the OS you have a better chance of getting through unscathed. -- Greg Harp |"How I wish, how I wish you were here. We're just two |lost souls swimming in a fishbowl, year after year, greg@ccwf.cc.utexas.edu|running over the same ground. What have we found? s609@cs.utexas.edu |The same old fears. Wish you were here." - Pink Floyd
hbrinch@icoast.UUCP (Henrik Brinch) (04/04/91)
> Memory can indeed be considered a problem, but only for machines that > don't have much of it. This is easily determined by AvailMem() and, Usually game programmers designed games for 512K (standard) models (at least the past years... probably changing when RAM prices decrease). > frankly, if a game can allocate the memory it needs via AllocMem(), > it should. A little cleverness, like NOT using an absolute origin, > means the game will run that much better on even minimally expanded > machines. > It's too dangerous, just because it works NOW doesn't mean it will work > later... at the very least one should AllocAbs() it to make sure it > isn't being used, and what happens if you find that it *IS* being used? > You can't run your game at all then. > > Any autoconfig board's driver can allocate memory anywhere, and it can > occur before your game starts up, and it can be SENSITIVE to being > ripped out from under it.. one cannot make the assumption that > the memory is all free. One can't even assume he will be safe if he > turns off all the interrupts! This is why so many games break when > you, say, have a bridgeboard in your system (though not necessarily > for the above stated possible scenerio). Yep, that's what I found out! Another thought could be the difference in memory allocation between NTSC/PAL models. NTSC screens requires less memory and therefor it can result in memory-allocations a place you wouldn't have dreamed of (as garage-hacker!). > The funny thing is that it is so EASY to write relocatable code.. Some thinks its easier just to put the whole program for $c0 and upward! People who thinks relocatable code is difficult or annoying shouldn't be programming at all :) > incredibly easy. I fail to understand why game programmers insist on > assembling one big program in one shot to an absolute location when > development goes much faster when you break it up into smaller modules > that generate objects... so when you make a change you are changing > only ONE SMALL object module and relinking instead of reassembling the > whole thing. Because the average game-programmer hasn't any kind of education in either structured-programming or in how to plan a project. Their knowledge are self-taught and it's hard as h*ll to convince a game-programmer to make use of some of the OS-routines (partly I understand that) but why some doesn't make 680x0 compatible code and some make those damn processor pause's - that's really difficult for me to understand! > It took me about 2 hours to figure out the Amiga object file format, > and only 5 minutes to understand the executable format. A game doesn't > need to know anything beyond the executable format if it loads/relocs > it itself, and even then it could be just as efficient to just use > LoadSeg(), depending on your situation. What I'm going to say know is probably very "flame-able" but I'll do it anyway : The real programmers can do everything (full control over the system via OS routines or if they want via direct hardware access) - but people who just take's over hardware (av. game-programmers) doesn't know ANYTHING about the OS - they shouldn't really be allowed to call themselves "programmers"! > -Matt Best Regards, InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3 ____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23 / \/ \ Denmark \ "C is SILVER - But ASM is GOLD"
bairds@eecs.cs.pdx.edu (Shawn L. Baird) (04/05/91)
greg@ccwf.cc.utexas.edu (Greg Harp) writes: >You'd rather sell the consumer a program that wipes out the OS than one that >required the user to shut down a program or two before running, but allowed >them to return to a functioning OS after the game had ended (w/o rebooting)? You miss my point. I feel that if a program is going to multi-task peacefully on my Amiga, I don't want it to have to shut down the workbench window. The gain from this is on the order of 32k to 64k. Not a small amount of memory, but not a large one either. >Somehow I'd figure that most programs that were left running (other than >VirusX or the like) were there getting _work_ done. Killing the OS can have >catastrophic results in such a case. Most users won't think about such a >thing until they get bitten... How much work do they get down when you have to close them all? Sure, they exit cleaner. If you take over the machine correctly, they resume running when you're done. >I wonder whose sales would drop because their OS-killing program stopped some >other program that happened to be in the middle of writing to a disk. At >least if you restore the OS you have a better chance of getting through >unscathed. Restore the OS implies that we left the OS at some point. Perhaps you should have said, at least if you don't disturb the OS. Anyways, I have several programs that Disable()/Enable() the machine for _long_ periods of time. The most catastrophic problems result from the serial line. What I'd really like to see is for Commodore to write an approved way of taking over the machine. Personally, I wouldn't like to count on the user cleaning up the workbench screen. If I'm that worried about it, since they'll have to quit _all_ running applications (since if the applications aren't running on the workbench screen that means they're running on a screen elsewhere, and if I'm desperate enough to close the workbench screen then I'll need all the other screens closed too), I might as well put it on a bootable disk to ensure no running programs. Some of the tests I've made when reading raw MFM data from floppy disks has involved doing this while the OS is validating the disk. I admit I haven't tried it in the middle of a write operation, and I'll do that now that you suggested it. Also, with all this talk of sales and whatnot, these are only opinions. I do not have any marketed software, nor do I have any large planned products in the work. My interest does, however, lie in creating commercial applications and games for personal computers, especially the Amiga. >-- > Greg Harp |"How I wish, how I wish you were here. We're just two > |lost souls swimming in a fishbowl, year after year, >greg@ccwf.cc.utexas.edu|running over the same ground. What have we found? > s609@cs.utexas.edu |The same old fears. Wish you were here." - Pink Floyd --- Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD The above message is not licensed by AT&T, or at least, not yet.
sschaem@starnet.uucp (Stephan Schaem) (04/05/91)
And what should people do when they want to use bank.especially when you have fousands of pointers that dont need to be 32 bit! or when you want you screen addresing only in the lower 16bit, or never change the blitter high adress etc... That can save you alot of space and time, depand on how you use it. But cant use the os for that (unless the system have absolute alloc). But we have an absolute allocate for those purpose, and can multitask. (you you find a bank:-) Imposing limitation is not something I like to mutch.And BANK are very usfull for some programing desing... Stephan.
sschaem@starnet.uucp (Stephan Schaem) (04/05/91)
And relocation take some space if you have tones of system structures. If you decide to use gadgets, and have around 2 3 hundres of them you dont have 10 30 bytes running away... I alway offer the posibilite to have long 32bit or relative 16bit pointer in my stucture... Try to move around system gadget for library needs.. (like requesters...) And its true that without the system strucure you dont have to use reloc posibility. And you can use relative very easelly for for 'paralle' or 'serial' structure (My names:-), using structure offet or label offset. And they could implement it today if the system had a structre type of all of then not just node type. All that to say: you could make reloc free programe but the system is a barier to that... Stephan.
farren@well.sf.ca.us (Mike Farren) (04/05/91)
bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >hbrinch@icoast.UUCP (Henrik Brinch) writes: >>Ethan Solomita writes: >>> take up 100K+, but then the workbench screen can always be >>> CLOSED! >>Why SHOULDN'T it be closed, I would say it's pretty strange to kill the >>system and leave the WB screen open ! >I think he was talking about the OS routine to close the Workbench screen. >There is only one problem. An application can not count on the ability of >the Workbench screen to be closed. Sure you can. If you really need the extra memory, you are perfectly within your Amiga-friendly rights to complain about it and ask for it. >Now granted, you could tell the user to go remove any offending >programs, but is this really what you want to sell to a consumer? Well, the only time it's a problem is if you need as much memory as possible. This means a 512K machine - and I don't see any problem with saying "Hey, I need a lot of memory" as long as you give the user the choice, instead of taking it all on yourself. >The OS itself eats up a lot more memory than just the workbench screen. >Although, granted, it's pretty small considering what it does (mostly >because a lot of it is in ROM). 80K of RAM. By actual test, NOT including Workbench screen memory. -- Mike Farren farren@well.sf.ca.us
ben@epmooch.UUCP (Rev. Ben A. Mesander) (04/06/91)
>In article <1991Apr7.150455.2256@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <18ec731b.ARN0f5b@icoast.UUCP> hbrinch@icoast.UUCP writes: [...] >I just fired up my Amiga 1000, Workbench 1.3.2. Hit ^D to abort loading, >and typed "avail". > >> If it isn't 200K it's less, but not much less.... still enough memory for >> quite some game-effects (levels/sounds etc.). > >Type Available In-use Maximum Largest >chip 421216 94648 515864 420328 >fast 0 0 0 0 >total 421216 94648 515864 420328 Peter, stop confusing the issue with facts! >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
ccplumb@rose.uwaterloo.ca (Colin Plumb) (04/07/91)
dillon@overload.Berkeley.CA.US (Matthew Dillon) wrote: > The 1.3 OS was compiled with greenhills, I believe, which is a pretty > good compiler. Would you rather the OS not have come out at all? Do > you know how many YEARS it would take to write all that stuff in > hand assembly? Much less debug it and enhance it. Not to detract from your point, but I stepped through some of the graphics.library code the other day and the quality makes me nauseous. One particularly memorable part in ScrollVPort: moveq #0,d0 move.w offset(a2),d0 ; ViewPort->Modes, I recall... move.l d0,d1 moveq #0,d0 move.w offset2(a2),d0 (play with d1 a bit) move.w d1,offset3(a3) Now, if the cast to 32 bits is in the source code, I admit it's a bit hard for a compiler to look and see that it's not necessary. But if it's not, it's pretty inexcusable to extend everything to 32 bits. And extending in d0 and then moving to d1 so you can clobber d0 again... well, I'm disgusted. > 28% is nothing compared to finding an algorithm that gives you an order > of magnitude better performance, and the chance of finding such an > algorithm is incredibly high when you have the time to think about it. A friend has a game in development. It's written in assembler. One part is too slow - it can't scroll smoothly on a vanilla 1000. So I'm rewriting the main loop for speed, in C. I'm just being careful not to do unnecessary work. More efficient data structures for keeping track of which enemies are off-screen, postponing or eliminating status display updates, that sort of thing. Assembler has its uses - 60% of the frame time is spent in two inner loops that I first came up with fiendishly clever algorithms for, debugged in C, then converted to assembler and spent weeks removing every last ounce of fat from. I'm very confident that, other than unrolling them even more, there are no spare cycles anywhere in the implementation, but more importantly, while one loop is fairly straightforward (it's only two-dimensional forward differencing and a bunch of rendering bit-bashing), the other involves rather non-obvious projective geometry and I'm absolutely positive that the entire cracker population of West Germany couldn't do the same thing at half the speed before the year 2000. Small-scale optimisations like assembler hacks are useful, but algorithms are where you get order-of-magnitude speedups. -- -Colin
jesup@cbmvax.commodore.com (Randell Jesup) (04/07/91)
In article <1991Apr7.000920.25630@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: >dillon@overload.Berkeley.CA.US (Matthew Dillon) wrote: >> The 1.3 OS was compiled with greenhills, I believe, which is a pretty >> good compiler. >Not to detract from your point, but I stepped through some of the >graphics.library code the other day and the quality makes me nauseous. >One particularly memorable part in ScrollVPort: > moveq #0,d0 > move.w offset(a2),d0 ; ViewPort->Modes, I recall... > move.l d0,d1 > moveq #0,d0 > move.w offset2(a2),d0 > (play with d1 a bit) > move.w d1,offset3(a3) > >Now, if the cast to 32 bits is in the source code, I admit it's a bit hard >for a compiler to look and see that it's not necessary. But if it's not, >it's pretty inexcusable to extend everything to 32 bits. And extending in >d0 and then moving to d1 so you can clobber d0 again... well, I'm disgusted. Note that graphics (and intuition) are the two main modules still in Greenhills. Greenhills was a reasonable compiler for ~1984, it's well below modern compilers, including SAS (especially with SAS's amiga-specific stuff - I would have hated to do Dos in Greenhills, since it needs it's args in d1,d2, etc). We consider graphics the next place we can reclaim large amounts of ROM space (with a bunch of work - note that Chris Green, the person who put forward the idea at Washington Devcon that the entire OS should be recoded in ASM, is now a senior graphics programmer here, as of a month or so ago). And I suspect it was promoting those values to ints (32-bit). However, it's possible that a good peephole optimizer, or really good global optimizer might be able to eliminate the extra instructions there. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
peter@sugar.hackercorp.com (Peter da Silva) (04/07/91)
In article <mykes.0692@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > This illustrates exactly what the rest of the industry says about Commodore. > The company comes across as not knowing what kind of machine they have. Thank god. If they had decided to sell a game machine I for one wouldn't buy it. You, apparently, want a company selling a dedicated game platform for your software: fine, code for the Sega Genesis. > Compare the A500 with the lowest-end Mac. The classic has the ability to run > a significant part of the business applications (it has 1Meg of RAM and separate > memory for screen). These days business applications require a hard disk as well. Put a hard disk on both your machines, and all of a sudden you have an extra 2 Meg on the 500. > I submit that you won't be crippling your OS by adding the additional functionality > of hard disk access. You weren't paying attention: they didn't say that. They said they hadn't written it that way and they don't have the resources currently available to rewrite it. They took advantage of the real power of the Amiga when they wrote it. Why don't you think about this: A500s with hard disks are going to have more than 512K of memory, so if you're loading from a hard disk... just leave the O/S alive. Make it "Requirements: Amiga with 512K. With hard disk, 1M is required". > You will only be making all these screamers on the net > happy because software written for the A500 will support more features of the > (far fewer) workstation class machines. What screamers on the net? By and large the folks on the net tend to think blowing away the O/S should be an action of last resort, not a basic part of doing business. > Just think of how well AMax would work if they had access to the low level drivers. Amax is a kludge. Have you heard of those guys writing a MAC ROM clone? I'd rather they spent the resources you want them to spend on rewriting the drivers to suit you, on working with them to run Mac programs under AmigaOS. > * Appendix A of the Amiga Hardware Manual tells you * > * everything you need to know to take full advantage * > * of the power of the Amiga. And it is only 10 pages! * If that's the case, what are you complaining about? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/07/91)
In article <mykes.0704@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > I'm sure you realize that the > vast majority of Amiga owners (those who one A500s) just stick in a > game disk and reboot and could care less about the OS. Then why are you flaming about the hard disk? Game machines don't have hard disks. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/07/91)
In article <18ec731b.ARN0f5b@icoast.UUCP> hbrinch@icoast.UUCP writes: > BUT judge for yourself, you have from $c0-$7ffff (app. 524000 bytes) > then break the CLI sequence and check your memory (AVAIL you know). > You have the CLI/WB screen (app.(!!!!!) 80K) + the exec/dos system do I > really have to tell you more? I just fired up my Amiga 1000, Workbench 1.3.2. Hit ^D to abort loading, and typed "avail". > If it isn't 200K it's less, but not much less.... still enough memory for > quite some game-effects (levels/sounds etc.). Type Available In-use Maximum Largest chip 421216 94648 515864 420328 fast 0 0 0 0 total 421216 94648 515864 420328 OK, the O/S is using a total of 94648. The workbench screen is overscanned, about 704 by 216. 76032 bytes for that, 1964 for "avail", leaves 16652 bytes used by all system data structures, interrupt vectors, dynamic data used by "avail", etc. Seems significantly less than 200K to me. And you can close the workbench screen without killing the O/S. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/07/91)
In article <24045@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: > >The OS itself eats up a lot more memory than just the workbench screen. > 80K of RAM. By actual test, NOT including Workbench screen memory. Wow, I just did the test myself and came up with ~16K. You must have had some extra stuff running. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/07/91)
In article <1991Apr2.114859.26216@phoenix.pub.uu.oz.au> terminal@phoenix.pub.uu.oz.au (Bernard Leach) writes: > Fair deal people! If you cant handle the time for a game to load, do you > *really* have time to play the game at all? You brought up Shadow of the Beast. My 5 year old son spends more time waiting for it to load than actually playing the game. You calll that a fair deal? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/08/91)
In article <1991Apr7.000920.25630@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: >dillon@overload.Berkeley.CA.US (Matthew Dillon) wrote: >> The 1.3 OS was compiled with greenhills, I believe, which is a pretty >> good compiler. Would you rather the OS not have come out at all? Do >> you know how many YEARS it would take to write all that stuff in >> hand assembly? Much less debug it and enhance it. > >Not to detract from your point, but I stepped through some of the >graphics.library code the other day and the quality makes me nauseous. Not at all, nobody is saying that C generates better code than hand written assembly .. on the 68000 it doesn't, no matter what kind of optimizations it does. It's the time factor (write, debug, & enhance) that really kills you with assembly. >Small-scale optimisations like assembler hacks are useful, but >algorithms are where you get order-of-magnitude speedups. >-- > -Colin And contrary to popular belief, the quickest algorithms take a while to figure out. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jesup@cbmvax.commodore.com (Randell Jesup) (04/08/91)
In article <1991Apr7.150455.2256@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >OK, the O/S is using a total of 94648. The workbench screen is overscanned, >about 704 by 216. 76032 bytes for that, 1964 for "avail", leaves 16652 bytes ^^^^^ 38016 ^^^^ + 4K stack ^^^^^ 50572 I suspect you have 2 floppies from those numbers (about 20-25K/drive). A lot less than 200K still. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
ccplumb@rose.waterloo.edu (Colin Plumb) (04/08/91)
peter@sugar.hackercorp.com (Peter da Silva) wrote: > I just fired up my Amiga 1000, Workbench 1.3.2. Hit ^D to abort loading, > and typed "avail". > > Type Available In-use Maximum Largest > chip 421216 94648 515864 420328 > fast 0 0 0 0 > total 421216 94648 515864 420328 > > OK, the O/S is using a total of 94648. The workbench screen is overscanned, > about 704 by 216. 76032 bytes for that, 1964 for "avail", leaves 16652 bytes > used by all system data structures, interrupt vectors, dynamic data used > by "avail", etc. I once forgot to plug any memory (even the 256K expansion) into my Amiga 1000 when I took it apart. For some reason, my compiles wouldn't work under make, but would if I typed them in by hand (Manx 3.6). Very perplexing... But Peter, workbench is only 2 bitplanes... that's 38016 bytes, so the O.S., sans WB screen, is 54668 bytes. Still pretty damn small! -- -Colin
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/09/91)
In article <1991Apr7.150747.2338@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <24045@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >> >The OS itself eats up a lot more memory than just the workbench screen. > >> 80K of RAM. By actual test, NOT including Workbench screen memory. > >Wow, I just did the test myself and came up with ~16K. You must have had some >extra stuff running. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. I just booted a 1MB A500 (one floppy) with the 1.3.2 workbench disk and came up with 467416 CHIP & 483568 FAST, or a total of 97K used including the normal, non-interlaced (default) workbench screen which takes ~32. That was by breaking out of the boot sequence. Running a memory flush, you get another 1K freed up. The AVAIL program takes 6K, and the CLI, including stack, around 5K. So, the grand total used by the OS if you boot a game and close the workbench screen is 52KB, leaving ~460KB free on a 512K machine. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
sschaem@starnet.uucp (Stephan Schaem) (04/10/91)
Well if you really think of getting 16K all the time its not the way to go.Well you could ask to unplug your external drives... Or you try to save/restore if possible (OS). Just say you need the first 512K, than move what there somewhere else! If you can save what is destroy, reboot when you quit and you you saved restore... 16K or 80K for a multitasking game is not that mutch, and could shut down its sounds by not loading them...