From Newsgroup: comp.sys.cbm

On 25 Jan 2004 17:09:39 GMT, ramlink666@aol.com (Ramlink666) wrote:

1mhz C64 is therefore not worth thinking about.

This seems to be the motto of some of the SuperCPU users. Yet they
don't realize the SuperCPU is dependent on the C64 even if the C64 is
just used as a "keyboard" for the SuperCPU.


Jason

--
E-mail #1: jkr[at]westol.com
E-mail #2: jkr7@juno.com
(Use E-mail #1 for a quicker response.)
Web site : http://www.westol.com/~jkr/
--
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

This seems to be the motto of some of the SuperCPU users. Yet they
don't realize the SuperCPU is dependent on the C64 even if the C64 is
just used as a "keyboard" for the SuperCPU.

Perhaps you took a small bit of what I said and responded to that?

Shaun.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Have a good point and this is why I choose a 20 MHz 65c265 for the SCPU-like project which I may begin (mostly for personal reasons) at some point after
I gathered some more info. The reason is, - 1.) It has built in I/O support
and abilities to communicate to other chips and thus makes the design have fewer components because I don't need to add a bunch of I/O. A second chip would be a GPC (Graphics Processing Controller). Given the general idea, it would be a chip capable of outputing graphics to the composite output or
SVGA. Secondly, be able to super-impose images from the TED or even
VIC/VIC-II (by concept) and ability discount the absolute black value when images carry on those attributes.

Given the option to drive two separate video output layers and splice them
in. Cool effects can be presented. Like the background/border layers of the VIC/VIC-II/TED would be one graphic layer. While sprites can be presented on both the "GPC" and the VIC/VIC-II. Anyway - it is primarily an idea. Of
course, I also have an idea for the sound as well and other aspects of
hardware buses. I love to have a higher speed expansion bus available for add-ons on this CPU accelerator. Its like a computer of its own. It be a
heck of alot nicer to have a 20 MHz I/O expansion port than a 1 MHz port.



"Jason" <tmr@cosine.spam.org.block.uk> wrote in message news:3EUQb.10929$YV1.5132@newsfep4-winn.server.ntli.net...

Okay, so the award for the most technically naive post of the thread goes to... =-)

The 3D Construction Kit isn't anywhere *near* the complexity of a Doom engine, certainly the display rendering will be far more intense; remember that we're not talking about flat planes which are just a couple of boundaries and a fill, this is texutre mapping and then you've got to get
the output from the rendering written to the screen in some way. The

C64's

display system (this, as pointed out elsewhere, doesn't apply to the

C-One)

*doesn't* lend itself to writing pixels in very well, the half FLI engines sort of simulate the PC's display so that they can get away with what they do, as i said that option is null and void the minute you're actually
writing to the bitmap. And that's *before* any colour boosting is added
(i'm not even talking about touching the attribute data yet) as well as

all

the fun of the fair to be gained from juggling with the WAD file...

To be honest, i *do* think it would be possible (speaking as a layman when
it comes to that kind of engine) but it's *certainly* not as easy as you
seem to think and there must be a reason why it's not been done so far

when

there are four engines that can be joystick controlled on the stock box

and

several more on rails.
-- ______________________________ _________________________________
/ /\/ ___/ / ___/ / / ___/\
/ Website: www.cosine.org.uk / / /\_/ / /__ / / / / __/\\/
/ ICQ: 44373717 IRC: TMR{C0S} / / /__/ / / / / / / / / /\ /_____________________________/ /_____/_____/_____/__/__/__/_____/ / \_____________________________\/\_____\_____\_____\__\__\__\_____\/TMR

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm


"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:eu11vb.ad3.ln@news.musoftware.de...

The "MIPS rating" doesn't say anything about the speed of a CPU. For

example,

the 80386 can has divide and multiply instructions on chip, whereas the

816

must emulate these in software. The 386 handles 32 bit quantities with one instruction while the 816 needs several instructions to do the same. So it

is

completely useles to compare the number of instructions a specific CPU is

able

to execute per second.

Regards

DOOM was a DOS program. Yeah, and takes several clock cycles for the 386 to perform some of those "32-Bit" instructions. If we want to play 32 Bit - we
can talk one word 65c032. Bring a demand and we can get one available for
use. Of course MIPS is BS but hey we can see new options too. Also you
re-write the game to use 16 bit instructions and optimize it. Anyway, so frelling what. You are producing less textiles anyway.

DOOM uses "texture" tiles. That is why it looks so "blocky". Its like our character cells. Of course these tiles are re-rendered on every movement.



--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Ramlink666 <ramlink666@aol.com> wrote:

The aim is for at least 16 levels.

doom.wad has ~40 levels, doom2.wad 32, so even with just 16 levels they are
too big for a FD2000.

I can't answer this question as I don't know about disk compression.

You cannot compress the data, because the wad file is not loaded into memory
as a whole. Compressing the data would slow down things considerably, whenever the wad file is accessed within the game.

A better option would be for the game to be on CD-Rom, as the IDE64 is available and compatible with the SuperCPU.

Requiring an IDE64 would be a good idea. The CMD HD will probably too slow because of the serial bus.

Regards


Uz


--
Ullrich von Bassewitz uz@spamtrap.musoftware.de
22:40:00 up 41 days, 33 min, 10 users, load average: 0.34, 0.14, 0.05
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

What stops us from later porting it to a future 65c265 CPU controller that sports a GPC (Graphics Processing Controller) capable of producing 24 bits
per pixel.

This chip would be running on a 20 MHz channel between the CPU controller
and it. Not 1 MHz. In fact it would be a minor change on the initializtion
and a rewrite of the rendering engine.

"Ramlink666" <ramlink666@aol.com> wrote in message news:20040125120939.24705.00000721@mb-m13.aol.com...

It is definately impossible then on a 1mhz 6502 based system, so setting

this

challenge for an unexpanded, 1mhz C64 is therefore not worth thinking

about.


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Jason" <tmr@cosine.spam.org.block.uk> wrote in message news:3EUQb.10929$YV1.5132@newsfep4-winn.server.ntli.net...

"Ramlink666" <ramlink666@aol.com> wrote in message news:20040125121624.24705.00000723@mb-m13.aol.com...

The difference is that WiNGS was started by coders who just got *on*

with

it; during the SuperCPU's lifespan to date, why hasn't anyone just got

on

with a Doom engine...?

There is no specific doom-type engine, however the 3d Construction Kit

under

the SuperCPU's control is really good to use. I can't see, therefore,

that

it

is impossible.

Okay, so the award for the most technically naive post of the thread goes to... =-)

The 3D Construction Kit isn't anywhere *near* the complexity of a Doom engine, certainly the display rendering will be far more intense; remember that we're not talking about flat planes which are just a couple of boundaries and a fill, this is texutre mapping and then you've got to get
the output from the rendering written to the screen in some way. The

C64's

display system (this, as pointed out elsewhere, doesn't apply to the

C-One)

*doesn't* lend itself to writing pixels in very well, the half FLI engines sort of simulate the PC's display so that they can get away with what they do, as i said that option is null and void the minute you're actually
writing to the bitmap. And that's *before* any colour boosting is added
(i'm not even talking about touching the attribute data yet) as well as

all

the fun of the fair to be gained from juggling with the WAD file...

To be honest, i *do* think it would be possible (speaking as a layman when
it comes to that kind of engine) but it's *certainly* not as easy as you
seem to think and there must be a reason why it's not been done so far

when

there are four engines that can be joystick controlled on the stock box

and

several more on rails.

Oh yes and if everyone had your brilliant line of thinking there would be a few less completed projects around for the C64. Eg: Contiki and the ethernet device.

Anyone thinking of creating Doom for the SCPU'd, IDE64'd- C64, dont let
jerks like Jason or Ullrich numb your senses. They are full of "ifs, ands
and buts" and dont seem to have a 1/4 of a brain between them. This game is possible! It may not be everything the ibm PC port is but it IS
possible.Just because it hasnt been done before means absolutely nothing. Instead of typing your frivelous drivel to the group, why dont you put your fingers to good use and start programming? Oh right.... I forgot.... The nay sayers are always the ones that cant program but think they know everything. Doom64 doesnt need to be "just like" the ibmPC port- just as close as
possible or the best that can be done with the hardware given.What is so
hard to understand about that! SHEESH!

Leo

--
Im looking for Commodore Cartridges! Got any? Check out my tradelist
& Gameboy Advance items for sale at http://www.commodore64.allhell.com




--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

On 25 Jan 2004 21:03:41 GMT, ramlink666@aol.com (Ramlink666) wrote:

This seems to be the motto of some of the SuperCPU users. Yet they
don't realize the SuperCPU is dependent on the C64 even if the C64 is
just used as a "keyboard" for the SuperCPU.

Perhaps you took a small bit of what I said and responded to that?

I did and yes, perhaps out of context from what you were saying. But
that sentence represented some attitudes so well that I couldn't pass
up using it.


Jason

--
E-mail #1: jkr[at]westol.com
E-mail #2: jkr7@juno.com
(Use E-mail #1 for a quicker response.)
Web site : http://www.westol.com/~jkr/
--
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

A write around, plug a GPU cartridge. In fact, I have a design "conceptual" model for a 65c265 which you have the ability to output video. BTW: What
stops the SuperCPU from having a video processor on the SuperCPU's 20 MHz
bus ???? No I/O !! ?? Solution, use a 65c265 controller which has its own
I/O support and support for communicating with co-processors (which can
include a GPU) in a star network fashion. This is the model for my CPU accelerator concept.

10 fps - what's wrong with it. Since it is still rather fast. Anyway, how
fast can you move around on a joystick. Oh, well.
Anyway, the slow CPU can be clocked faster Ullrich. Just adjust the clock source and power to it. Of course a heatsink
is my suggestion or whatever to keep the chip cooled. Typically a P4 is overclocked to begin with because of the need
of a heatsink/fan and it is rated only to run at its rated clock rate with a Heatsink/Fan package. WDC's chips are rated to
its speeds without the need of heatsink/fan. So it may very well be able to
run reliable and be rated at higher MHz speeds
if you follow the same rating rules as Intel. Intel's speed rating runs are based on the chip's reliability to operate at a given
clock frequency with their "stock" heatsink/fan package.

As long as the WDC CPU is not operating in excess of 70 degrees Celsius.
Keep you can keep it cooled to around 30-45 degrees celsius
then that heatsink/fan or cooling system of choice is reasonable proper to operate the chip. It is heat that kills the chip not the voltage or the
wattage except that they make the chip run faster and hotter. So as long as
you can keep it running stable (great). Of course, timing issues may occur
if the other devices are'nt "overclocked" proportionally. Of course video
can be a problem to handle or deal with so this is why you have to consider carefully or adjust sync capabilities. 20 MHz syncs well with devices at 1
MHz and so does 2 GHz as they can be reasonable divided down.

Because of the typical .8 micron fabrication - you would not want to run it faster than 250 MHz without a heatsink+fan for a 233-266 MHz Cyrix M2
heatsink. Well that is because the chip surface space is about the same or reasonable enough for one. Of course - we would have find a way to lock the heatsink on though. Just consider the volume of heat and how well the heatsink/fan can pull the heat away from the chip. That is the key to
keeping those P4s from frying.

"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:5i21vb.ad3.ln@news.musoftware.de...

How? There is no way to work around the color limitations of the VIC. Of course something like FLI could be use. But it needs a real lot of CPU

power

just to keep the graphics on screen, and there's still the limit of 16

colors

total and the limited screen resolution.

Forget that. Doom needs about 20fps to be playable. This means that you

will

need to copy the whole screen 20 times per second. The VDC is simply not

fast

enough to do that.

While the CPU is the same, the big difference is the video output. The

video

resolution, the available colors and the weird pixel addressability are

the

killer reasons why DOOM will NOT run on a C64. All these reasons will go

away

with the C-1. There's still the slow CPU, but this is a problem that

may(!) be

worked around by some clever ASM programmers and stripping down the

feature

set.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Leo <commodore128@hotmailspamtrap.com> wrote:

This game is
possible! It may not be everything the ibm PC port is but it IS
possible.Just because it hasnt been done before means absolutely nothing.

Who will buy a SCPU, an IDE64, and pay money for a game that is the same as a 10 year old PC game, just slower and with a lot worse graphics? Especially if much improved versions of this game are available on the net for free?

The nay
sayers are always the ones that cant program but think they know everything.

I would say the DOOM protagonists are the non programmers. Every C64
programmer knows about the display resolution and available colors. DOOM with half the resolution and just 4 colors per character cell - get real! Do you know how many colors you need just for the shadows and light effects?

Why not try something that has at least a small chance to get realized? Like porting Wolf3D to the C-1?

Regards


Uz


--
Ullrich von Bassewitz uz@spamtrap.musoftware.de
23:33:48 up 41 days, 1:27, 10 users, load average: 0.02, 0.27, 0.54
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Then HD is required or a ZIP drive.
Clear and simple. Otherwise, we got that Colorado tape drive option. ;-))

(120 MB and runs on a Floppy bus. Just need an adapter and a slightly larger case).

DOOM was never ran on Floppies except for through the use of special methods
of segmenting the file into 1-1.25 MegaByte segments then is pieced back together in the end by a utility. Of course with the FD (we could look at
1.5 MB segments but 1.25 MB for buffer room).

"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:oo21vb.ad3.ln@news.musoftware.de...

uz@trixie:~/dl/tmp/legacy-1.41$ l doom.wad doom2.wad
-rw-rw-r-- 1 uz uz 12281189 8. Nov 22:58 doom.wad
-rw------- 1 uz uz 14604584 9. Nov 20:28 doom2.wad

The WAD file for Ultimate DOOM has 12 megs, the DOOM II WAD file has 14 megabyte. I have no idea how this could fit on a FD2000:-)

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

You chop up to WAD file into segments and the restore utility brings them
back on disk.
On MS-DOS/Windows 3.1-95 used utilities that chops up a large file (eg. a 15
MB file) into 1 MB segments spread over say 15 disks.
They were not exactly compression or archiving in the sense of a SDA file or
an ARC file. It was another method. When the files are restored, the pieces
are put back together. If everything worked out ok, the file is not
corrupted and will work.


"Ramlink666" <ramlink666@aol.com> wrote in message news:20040125135712.20558.00000397@mb-m21.aol.com...

The aim is for at least 16 levels. Say the game for FD is spread over 8

disks.

I can't answer this question as I don't know about disk compression. But,

for

instance, this is better than many disk sides on a 1541. Most people would probably install their game on their RAMLink or IDE64 anyway regardless of

how

many disks the game requires.

A better option would be for the game to be on CD-Rom, as the IDE64 is available and compatible with the SuperCPU.

Shaun.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Leo wrote:

Anyone thinking of creating Doom for the SCPU'd, IDE64'd- C64, dont let jerks like Jason or Ullrich numb your senses. They are full of "ifs, ands
and buts" and dont seem to have a 1/4 of a brain between them.

Excuse me?

First, Jason and Ullrich have presented *facts*. If you have facts to
reply with, present them. If you don't, shut up. Either way, there is *absolutely* *no* *need* to resort to personal insults.

Second, you'd do better to check *some* facts before you rant.

Ullrich -- the guy with 'less than half of 1/4 of a brain', to
paraphrase what you wrote above -- is the primary author of cc65, a cross-compiler and cross-assembler package for a wide variety of 6502-
based systems. Furthermore, I've 'met' Ullrich in several newsgroups,
and each and every of his posts has come across as well-informed and
fair.

I don't know as much about Jason, but AFAICT from his web site, he's
been coding demos for Commodore 8-bits for some 15 years.

To summarise: two experienced programmers tell you it won't work. You
don't have to believe that, of course, but insulting them doesn't make
you look any smarter.

Just because it hasnt been done before means absolutely nothing.

Well, it means *at the very least* that no-one sufficiently qualified
ever considered it (a) doable and (b) worth doing.

Instead of typing your frivelous drivel to the group, why dont you put your fingers to good use and start programming? Oh right.... I forgot.... The nay sayers are always the ones that cant program but think they know everything.

You'll really want to rethink that line -- re-read what I wrote above.

Regards,
Michael
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Michael J. Schülke" <news0310@mjschuelke.de> wrote in message news:MPG.1a7e6a8311278009989995@News.individual.DE...

Leo wrote:

Anyone thinking of creating Doom for the SCPU'd, IDE64'd- C64, dont let jerks like Jason or Ullrich numb your senses. They are full of "ifs,

ands

and buts" and dont seem to have a 1/4 of a brain between them.

(Actually, it's Ullrich's turn with the quarter of a brain this month, i'm
so looking forward to February 2nd (shipping, doncha know) because the
puddle of dribble by my computer is getting quite deep now!)

I don't know as much about Jason, but AFAICT from his web site, he's
been coding demos for Commodore 8-bits for some 15 years.

Games and demos since about 1987, although i specialise in "oldschool" demos rather than 3D stuff because i don't find them interesting personally. Presently winding up a conversion of my own game Reaxion to the Atari 8bit series and halfway through porting it to the Plus/4 and not sure what to do next on the Breadbin. But enough of me, back to the topic in hand.

The only people really *qualified* to offer opinions are guys like Graham/Oxyron, the Noname team, Cameron and so forth 'cos they've *done* the engines in chunky modes before. Certainly comparing the 3DCK engine to
Doom's is like comparing a Sinclair C5 to a Ferarri; both get the job done
but one just looks a thousand times better and is far more complex under the hood. Leo, feel *free* to prove the quarter brain club wrong; as Michael points out us two jerks aren't exactly novices when it comes to the breadbin (well i am, but Ullrich isn't! =-) and if you feel you can do a better job
then the SuperCPU-specific Virtual Assembler is available as a download from www.protovision-online.de and we've already had pointers to the Doom WADs
and source. How long d'you reckon you'll need?
-- ______________________________ _________________________________
/ /\/ ___/ / ___/ / / ___/\
/ Website: www.cosine.org.uk / / /\_/ / /__ / / / / __/\\/
/ ICQ: 44373717 IRC: TMR{C0S} / / /__/ / / / / / / / / /\ /_____________________________/ /_____/_____/_____/__/__/__/_____/ / \_____________________________\/\_____\_____\_____\__\__\__\_____\/TMR


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Ullrich, with your logic - who will ever buy or would have bought a 20 MHz
CPU accelerator. Even in 1996 when the SuperCPU was released, everyone who bought that device didn't do it according to your logic. They did it because they wanted something that will improve their Commodore experience.
You know, it isn't that hard to Bus Master an x86 and control a PC
motherboard with a Commodore and make it an extension. Of course, what is
wrong with even an idea to "update" the Commodore platform with updated graphics/sound and an upgraded version of the 6502s like the 65c032/064 when they come available. To make these thing available, there needs to be a
demand. How many would like to make their Commodore's 200-4000 TIMES faster. Some can say that under 32 Bit environments that a 4 GHz 65c032 would
execute 32 bit instructions upto 16,000 Times faster then a 6502 or even
faster than that. Yet the 64 bit model would process that 32,000+ TIMES
faster than a 6502 at 4 GHz.

Now, that is FAST. Take 4 GHz or 4,000 MHz and double or quadruple the bus width and sport pipelining and what do you get. Imagine what 8x the bus
width be like. Executing a 64 bit instruction in one to two instruction
cycles average. Imagine pipeling 8 instructions in a superscalar pipeline fashion. Even a P4 is lightyears different architecturally than an 8086 but
is yet natively backward compatible (to some reasonable extent). So what is wrong with modernization of this sort on a 65c816 architecture. Take an 8086 and you wouldn't think it could have been expanded. But you look at the
Pentium 4 - after the fact that Intel has done so over 10x since the introduction of the 8086. It was said that the 6502 couldn't be expanded to
16 bit. So saying it couldn't only means that you have given up. Go back to your Windows computer and quit wasting your precious time on the "inferior" Commodore. What - your not satisfied with the superior Windows computer ????

Yet now at the end of your message - you talk about the porting of it for
the C-One. Once it is released - then we can see something. Until then - the C-One isn't worth committing to. There are only 53-54 maybe 55 people who
have a C-One in testing. If more people by a C-One then the people who
bought a SuperCPU. Say if 30-50% of the overall Commodore 8-bit users and
about 2-10% of those who don't have a Commodore 8 bit and uses an emulator
buys it then we have something to look at. It sure the heck have to exceed 1,000 individual users buying at least one unit on a global scale.

I would enjoy making a few things for that unit but as it looks, if I decide
to buy one, its for personal desires. As for developing for it, I can't say
at this time except for what it is now.



"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:8fh1vb.qc4.ln@news.musoftware.de...

Who will buy a SCPU, an IDE64, and pay money for a game that is the same

as a

10 year old PC game, just slower and with a lot worse graphics? Especially

if

much improved versions of this game are available on the net for free?

I would say the DOOM protagonists are the non programmers. Every C64 programmer knows about the display resolution and available colors. DOOM

with

half the resolution and just 4 colors per character cell - get real! Do

you

know how many colors you need just for the shadows and light effects?

Why not try something that has at least a small chance to get realized?

Like

porting Wolf3D to the C-1?

Regards

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Ullrich,

I do own a SCPU, but thinking of a DOOM clone in 160x200 with 16 colors (4 colors within each 8x8 square) makes me laugh. I'm running Legacy Doom on my

This is exactly the point I was trying to make in an earlier post.
Even if these guys pull off a Doom-clone, the question is how
enjoyable is it going to be? It certainly isn't even going to come
close to the original.

MikeC
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm


"Michael J. Schülke" <news0310@mjschuelke.de> wrote in message news:MPG.1a7e6a8311278009989995@News.individual.DE...

I don't know as much about Jason, but AFAICT from his web site, he's
been coding demos for Commodore 8-bits for some 15 years.

As for Jason, I am not going to resort to saying that they don't know
anything but may express some aspects of their logic may not make sense but
I do agree with them that it isn't going to be a cake-walk to make DOOM for
the C64 with or without a CPU upgrade. For an evolved "next-generation" Commodore with a '032 or '064 or a higher speed '816 or a 65c265 microcontroller running at 50 MHz or more wouldn't be that big of a deal.
Even at 20 MHz. But the C64 does have a limited 4-bit graphics chip running
at 1 MHz. Even the Plus/4 "graphically" may possibly surpass the VIC-II in where it matters. Of course without "hardware" sprites, it may make it more challenging unless a special GPU is added with a hardware sprite engine that would be super-impossed on top of the TED image. Well, that is what a sprite does anyway - superimpose its image through integrated "genlocks" anyway. On the VIC-II, we don't generally think of it that way as it is part of the integrated circuit.

Jason - happens to be one who did do some impressive graphics on a Plus/4.



--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Well, not on a PC but on a RAMDisk (RamLink) this can present a different
way of angling the objective.
Why couldn't it be - in that way. :-)

Then whatever part is needed is mirrored to the SuperRAM. An idea.

The CMD HD wouldn't be because of the SuperCPU because the SuperCPU presents
a parallel bus.
So I wouldn't say it be too slow. So you have two options here.

Lets make it simple - you need SuperCPU with SuperRAM (populated with - 8 or
16 MB ) and an HD (whether it is CMD HD or the IDE) or a Zip. A low-cost
but not to bad would be using a IDE drive in a serial bus inside a 1571
case. Note: you would want that option to support the FAST Serial Bus mode. That option is a potential choice of option too. I have mentioned Zip as an option. Another may be an ol' higher-speed tape drive. Note: These are not
as fast as an HD from my understanding.


"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:0bd1vb.fo3.ln@news.musoftware.de...

doom.wad has ~40 levels, doom2.wad 32, so even with just 16 levels they

are

too big for a FD2000.

You cannot compress the data, because the wad file is not loaded into

memory

as a whole. Compressing the data would slow down things considerably,

whenever

the wad file is accessed within the game.

Requiring an IDE64 would be a good idea. The CMD HD will probably too slow because of the serial bus.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:8fh1vb.qc4.ln@news.musoftware.de...

Who will buy a SCPU, an IDE64, and pay money for a game that is the same

as a

10 year old PC game, just slower and with a lot worse graphics? Especially

if

much improved versions of this game are available on the net for free?

I think it's more for people who already own a SCPU and other things, or to help stimulate those people who are thinking about getting one anyway.

I would say the DOOM protagonists are the non programmers. Every C64 programmer knows about the display resolution and available colors. DOOM

with

half the resolution and just 4 colors per character cell - get real! Do

you

know how many colors you need just for the shadows and light effects?

C64 graphics mode workarounds have been done for as long as the C64 has been around, and basic lighting effects with gouraud shading and bump mapping are old hat by now. Obviously, pixel-for-pixel rendering comparable with the
VGA version is impossible, but I for one think it'll be interesting to see
how far people actually do get along with this project, and what tricks they use along the way.

--
White Flame (aka David Holz)
http://www.white-flame.com/
(spamblock in effect)


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Why not try something that has at least a small chance to get realized? Like >porting Wolf3D to the C-1?

Why set challenges in the first place then? We don't want to make it easy.

The official site is now up and running, although you can only read the article from Commodore Scene so far, which is in PDF format.

Nobody is suggesting that this project will be a big seller, although there are people who want a SuperCPU anyway, and starting this challenge has made them more interested in buying one.

At the end of the day, I have money to spend, and I want to see a C64 version of Doom exist using the SuperCPU. And Yes, I will continue to spend my money on my C64. People have a free will, and can do what they like.

BTW - I will personally put in a further €200 if you take up this challenge Uz. That would be €500 currently up for grabs, and the challenge is less than 1 month old already.

See the site for further updates http://www.commodorescene.org.uk

Shaun.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Totally agree !!!!

The VIC-II doesn't support color definition for every pixel except for in Hi-Res Bitmap. This is due to the limitation of the VIC-II's memory addressability. Though it is technologically possible to reduce resolution
to get that and that is exactly what multi-color bitmap mode does.
Reason, 16K addressing is too limiting despite it can be addressed in
whatever space within a 64KB zone. It would take 32 KB of RAM to map the
whole area out. Of course it is technically known to be possible to get
160x200 pixel color definition and squeeze it in 16 KB. Though this is why
the VIC-II is too limiting to do things "as" well as the IBM PCs. It is like trying to run Doom on the "IBM PC & PC jr. & XT" with the stock graphics
chip.

I would be interested in how this can progress and this project be a testing grounds for developers to make a genre of new games using the design model
of Doom. Of course - we have options to change the rendering process. Who
says you couldn't "raycasts" and reduce calculation. Actually to some
degree, it might actually look better. Since Doom's attempt was rather
pitiful and somewhat ugly. We can use better techniques if it overall works
and still presents a reasonably close presentation of the environment. Maybe wood would actually look nicer not necassarily more real.

I actually would like to see a version for the C-One but hey - one step at a time. We can improve the rendering engine to make use of the SuperVIC's graphics capabilities. Even sound might be cooler.


"White Flame (aka David Holz)" <whiteflame52@y.a.h.o.o.com> wrote in message news:bv2c3r$423$1@barad-dur.nas.com...

I think it's more for people who already own a SCPU and other things, or

to

help stimulate those people who are thinking about getting one anyway.

C64 graphics mode workarounds have been done for as long as the C64 has

been

around, and basic lighting effects with gouraud shading and bump mapping

are

old hat by now. Obviously, pixel-for-pixel rendering comparable with the
VGA version is impossible, but I for one think it'll be interesting to see how far people actually do get along with this project, and what tricks

they

use along the way.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

The only people really *qualified* to offer opinions are guys like >Graham/Oxyron, the Noname team, Cameron and so forth 'cos they've *done* the >engines in chunky modes before. Certainly comparing the 3DCK engine to >Doom's is like comparing a Sinclair C5 to a Ferarri; both get the job done >but one just looks a thousand times better and is far more complex under the >hood. Leo, feel *free* to prove the quarter brain club wrong; as Michael >points out us two jerks aren't exactly novices when it comes to the breadbin >(well i am, but Ullrich isn't! =-) and if you feel you can do a better job >then the SuperCPU-specific Virtual Assembler is available as a download from >www.protovision-online.de and we've already had pointers to the Doom WADs
and source. How long d'you reckon you'll need?

Nobody was comparing the 3d Construction Kit to anything. I simply pointed out how well that run (under the SuperCPU's control) for a 3d enviorment that dates back to 1987/88.

Nobody is also suggesting that you need to use the WAD files, it was a suggestion from an ex-employee of iD Software.

Again, the criteria that needs to be met is under the heading "What is the programming criteria?" as follows:

"What is the programing criteria ?

The first stage of the development would be to recreate the first level of the original (PC) DOOM as close as possible. I will be very strict about the finished product and no money will be handed out until I am satisfied, as described above. Once programming is underway it might be worthwhile to remember the following points :

* NTSC compatibility would be beneficial but not a necessity for the first version.
* The original (PC) DOOM is able to increase/change levels with the option of installing different .WAD files. This would be a great option for the Commodore version too as it would also make it easier to create a follow up version (DOOM2).
* Interlace those graphics - lets get some real colour and definition on the screen !!"

There is nothing there about porting Doom, also note the words "as close as possible."

The latter parts are considerations. Again, nobody is saying that the original wad files need to be used. This will come down to the programmers, obviously.

The minimum hardware requirements are:

"What hardware will be required as a minimum ?

* Mouse and keyboard control (joystick can be an option)
* SuperCPU
* SuperRAM/REU option
* Compatibility with all popular drives where appropriate (i.e., 1541 disks may not have sufficient storage space).
* Large storage devices (RAMLink, CMD HD or IDE64, etc.)."

So, even if the wad files are used, there is no real limit to the amount of storage space available. If you read the full text, from the PDF, Allan is limiting the game to 16mb's anyway, ie, so it would be possible to run from a RAMLink.

The same offer goes to you Jason. Take up this challenge (before Uz), and I'll personally put in another €200.

Shaun.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

ramlink666@aol.com (Ramlink666) writes:

Allan isn't looking at it from a technical point of view

If DOOM with its texture mappings, huge levels and colour requirements
are considered close to impossible to get to, maybe it would be wise
to already in the early stage of the development aim at a very good
hi-res 3D engine using only solid surfaces and build its own scenario
around it.

Nobody would have to compare with the original version, the finished
game could be just as good as the hardware (SuperCPU or not) allows
and beyond everyone's expectations. Wolfenstein 3D was already
proposed. Maybe even that has too much detail to be satisfactory.

To mention how much more money you are willing to invest will not
help the VIC-II hardware, not unless you find a time machine and
goes back some 25 years and convince Commodore technicians to spend
your hard cash on even greater video chips.

--
Anders Carlsson
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Ramlink666 <ramlink666@aol.com> wrote:

Why set challenges in the first place then? We don't want to make it easy.

Please don't get me wrong, I don't have anything against challenges in general and nothing against this special challenge. However, I do think that this special challenge is raising expectations to a level where it is almost sure that people will be disappointed once they see the final result, and this is
a bad thing and will not help the Commodore Community or the SCPU.

Besides that, I cannot remember a successful CBM project designed by a commitee. Great projects of the past were started by knowledgeable people who wrote code for themselves, and went public when they had something to show. This made sure that the project specs were realistic.

At the end of the day, I have money to spend, and I want to see a C64 version of Doom exist using the SuperCPU. And Yes, I will continue to spend my money on
my C64. People have a free will, and can do what they like.

This is of course right, and I'm sorry if any of my posts sounded like I would suggest not to spend money for this project. But please keep in mind that "as close as possible" will in this case mean, that the result will be quite different from the original, and the differences are all on the bad side.

Maybe someone should recreate two or three scenes from the first level of DOOM as static images, so people can get a feeling how the results will look. In fact, static images will look even better because it is possible to optimize every aspect. Or have a look at the Mood pictures in the PDF document. Are you really sure people will prefer this over the original DOOM? Because using the SCPU will not give you better graphics ...

Again, don't get me wrong: Mood is a great program and a good example what experienced programmers can do with a 20 year old machine. But the challenge implies that it is possible to create something that is comparable to the original DOOM. Look at the pictures yourself. Do you think DOOM would have taken the gaming world in storm with this sort of graphics? And DOOM is now 10 years old. People are used to 3D graphics cards that allow almost real world like graphics. Have you seen the DOOM3 trailer?

BTW - I will personally put in a further â?¬200 if you take up this challenge Uz. That would be â?¬500 currently up for grabs, and the challenge is less than
1 month old already.

My rough estimate is that this is less than a pound per hour. You will need people more interested in glory than in riches:-)

Regards


Uz


--
Ullrich von Bassewitz uz@spamtrap.musoftware.de
10:27:44 up 41 days, 12:21, 10 users, load average: 0.00, 0.00, 0.00
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Ramlink666" <ramlink666@aol.com> wrote in message news:20040126023320.18928.00000771@mb-m28.aol.com...

Nobody was comparing the 3d Construction Kit to anything. I simply pointed

out

how well that run (under the SuperCPU's control) for a 3d enviorment that

dates

back to 1987/88.

i don't think anybody doubted that the 3D environment itself was possible,
it's the rendering engine and the actual building of the game that's being questioned; i reckon it's do-able but it'd be a bitch, Cameron seems to
agree if i'm reading his post right, Groepaz has said elsewhere that the
engine is pretty easy but getting an accurate conversion running around
it'll be the hard bit and Ullrich doesn't seem to think it's possible with
any reasonable spec. i *think* we're all talking about rendering to a stock 160x200 bitmap here, nobody seems willing to consider interlace or hogging large wedges of the CPU time with a FLI routine or interlacing (which
doubles the load on the renderer) except the non-programmers.

The same offer goes to you Jason. Take up this challenge (before Uz), and

I'll

personally put in another ?200.

Looking at this from a one-person project (my usual mode of working, bar the sound) it's several years worth of work to learn 65816 and Virtual
Assembler, read up on 3D routines and raycasting techniques, figure out the
WAD formats to rip and convert the data (i don't have any C++ so a fair bit
of backward engineering would be required) and then stick everything
together in a functional form. i honestly don't want to do any of the above apart possibly from learning 65816, i certainly don't want to go through a couple of years of playtesting when i don't *like* the original game, i *really* don't want or indeed need the pressure involved generally and, with all due respect, that figure with a couple more noughts on wouldn't be
enough to change my mind about any of the above. If i were into coding
games for money, i'd have learnt ARM and gone GBA by now...
-- ______________________________ _________________________________
/ /\/ ___/ / ___/ / / ___/\
/ Website: www.cosine.org.uk / / /\_/ / /__ / / / / __/\\/
/ ICQ: 44373717 IRC: TMR{C0S} / / /__/ / / / / / / / / /\ /_____________________________/ /_____/_____/_____/__/__/__/_____/ / \_____________________________\/\_____\_____\_____\__\__\__\_____\/TMR


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:kuo2vb.kp6.ln@news.musoftware.de...

Besides that, I cannot remember a successful CBM project designed by a commitee. Great projects of the past were started by knowledgeable people

who

wrote code for themselves, and went public when they had something to

show.

This made sure that the project specs were realistic.

Oh, don't start me on that... i got dragged into one of the Zelda
"conversion" projects that sprang up a few years back as a technical adviser and the committee never got past deciding which screen mode to run in
despite being told by me and the other programmers aboard that scrolling a bitmap at multiple pixels a frame is quite difficult... =-)
-- ______________________________ _________________________________
/ /\/ ___/ / ___/ / / ___/\
/ Website: www.cosine.org.uk / / /\_/ / /__ / / / / __/\\/
/ ICQ: 44373717 IRC: TMR{C0S} / / /__/ / / / / / / / / /\ /_____________________________/ /_____/_____/_____/__/__/__/_____/ / \_____________________________\/\_____\_____\_____\__\__\__\_____\/TMR


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Jason" <tmr@cosine.spam.org.block.uk> writes:

rendering to a stock 160x200 bitmap

Between thumb and index finger, how much would be gained if the
viewport was shrunk to 1/4 of the screen (80x100 in multicolour)?
Is it the calculations and texture manipulations which takes most
time, or the actual drawing? While a such mini windowed DOOM game
may not be as attractive as full screen, you have a lot of room
for a static score display. :-)

--
Anders Carlsson
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

May I point out that I have never actually played Doom on any platform. My favourite type of game is horizontally scrolling shoot 'em ups, and as Metal Dust is on the verge of release, it would be pretty pointless asking for such a game for the SuperCPU.

My experience of 3d games isn't much beyond the freescape games currently available. Allan is the Doom fan, and because he wanted it to be released, he is the one who started it. I am supporting this venture because I will benefit from it, and I would like to see more SuperCPU-only games. This isn't going to happen unless people are motivated to do so, even if they only program in their spare time. Nothing motivates people like money in my experience.

Also, I'll be play-testing any submissions from having no experience of the original, and will be looking for game play above all else. Allan will be looking how close it is to the original. I will then give my opinion of the project as a game and not as a Doom clone. This fresh prespective should mean it is at least playable. It is up to the programmers and developers to sort out technicallities.

Shaun.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"UvB" == Ullrich von Bassewitz <uz@spamtrap.musoftware.de> writes:

Maybe someone should recreate two or three scenes from the first
level of DOOM as static images, so people can get a feeling how
the results will look.

Here are a few quick and dirty conversions:

http://www.cling.gu.se/~cl3polof/doom64/

I haven't actually bothered to restrict it to 4 colours per 8x8, so
some of these actually look a little bit better than they'd do on a
real C64.

160x200: MC FLI. Too slow to be usable.
80x200: AFLI with $f0 bitmap. Possibly fast enough.
80x200-stag: Same as above, but with a black mask.
80x50: Chunky 4x4. No probs.
2x4: Interlaced 4x4. Also fast enough.
ifli: Interlaced MC FLI. Even slower than plain FLI.
iafli: Interlaced 80x200.

Now to be fair you could spend time retexturizing, and movement adds a
lot more perceived resolution, but I have to say that I'd much rather
play the original on a $50 486, instead of on my C128 with SuperCPU.

--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + MagerValp@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"MagerValp" <MagerValp@cling.gu.se> wrote in message news:p14vfmyn7bc.fsf@panini.cling.gu.se...

"UvB" == Ullrich von Bassewitz <uz@spamtrap.musoftware.de> writes:

Maybe someone should recreate two or three scenes from the first
level of DOOM as static images, so people can get a feeling how
the results will look.

Here are a few quick and dirty conversions:

http://www.cling.gu.se/~cl3polof/doom64/

I haven't actually bothered to restrict it to 4 colours per 8x8, so
some of these actually look a little bit better than they'd do on a
real C64.

160x200: MC FLI. Too slow to be usable.
80x200: AFLI with $f0 bitmap. Possibly fast enough.
80x200-stag: Same as above, but with a black mask.
80x50: Chunky 4x4. No probs.
2x4: Interlaced 4x4. Also fast enough.
ifli: Interlaced MC FLI. Even slower than plain FLI.
iafli: Interlaced 80x200.

Now to be fair you could spend time retexturizing, and movement adds a
lot more perceived resolution,

Using sprites for the enemies would make them standout more clearly from
the background at low resolutions. I can imagine that lowering the vertical resolution (160x100 or 80x100) would save a few cycles. Also some processor time could be saved by not using FLI on the bottom part of the screen where
the scores are displayed.

BTW: Is the SCPU fully occupied when doing FLI? It would be interesting to
know how much processor power is actually lost just for displaying the graphics.

but I have to say that I'd much rather
play the original on a $50 486, instead of on my C128 with SuperCPU.

The question is if the goal is a game that is playable and enjoyable, or a
if it is just about proofing that a game that resembles DOOM is possible on
a C64 + SCPU. Probably the most fun of CSDOOM64 would be in programming
rather than playing.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl



--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Peter van Merkerk <merkerk@deadspam.com> wrote:

Using sprites for the enemies would make them standout more clearly from
the background at low resolutions. I can imagine that lowering the vertical resolution (160x100 or 80x100) would save a few cycles. Also some processor time could be saved by not using FLI on the bottom part of the screen where the scores are displayed.

This is probably how I would do it. I programmed an animation player,
Silicon Dreams, for the SuperCPU and it ran in FLI mode. I was able to get around 12 frames per second. If I were to shorten the FLI screen, the framerate will increase to an acceptable level. Additionally, using
sprites over a FLI screen is *very* easy under the SuperCPU, so I'll
expect them to be used if a port is made.

BTW: Is the SCPU fully occupied when doing FLI? It would be interesting to know how much processor power is actually lost just for displaying the graphics.

The SuperCPU isn't fully occupied under the FLI mode. Once the badline
starts during a FLI mode, the SuperCPU can continue its normal activities. However, if the SuperCPU needs to access the host C64, then it has to wait until the badline passes. Theoretically, a programmer could time the
badline and use the 'dead-time' for the SuperCPU in making math
calculations during the badlines, and transfer the results to the host C64 when it's ready.

No, I will not program Doom SuperCPU 64 edition. :( My math skills really isn't enough and I don't have sufficient C skills to understand the Doom sources in any attempt of reverse-engineering. It is certainly an
interesting challenge and I hope someone out there can answer the bell!

Enjoy.
--
Todd Elliott
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Ramlink666" <ramlink666@aol.com> wrote in message news:20040126062835.24647.00000747@mb-m13.aol.com...

May I point out that I have never actually played Doom on any platform. My favourite type of game is horizontally scrolling shoot 'em ups...

Actually, scrolling blasters are my favourite field too (i've played and
indeed written enough of the buggers in my time!) and i've constantly nagged the PTV guys about the fact that Metal Dust won't run on stock kit so i'd
like to lay some *very* small claim to the appearance of Enforcer 2 even if
i don't deserve it! =-)

...and as Metal Dust is on the verge of release, it would be pretty

pointless

asking for such a game for the SuperCPU.

Metal Dust is a game that has been specifically written around the SuperCPU (Hoild of the Enhanced Newcomer team tells me that level 4 rocks the house)
so why not promote original game development rather than a port? The whole "wouldn't it be cool if X was on Y" attitude to some of the 8bit development community never ceases to amaze me, there are some people actively trying to wedge stuff from one format to another regardless of how it's going to
*play* when it gets there. i'd rather develop my own ideas (what few there
are =-) than port something else...

That said, if it *has* to be a big name game to do a bit of attention
getting, why not move something like Myst over? i'd suspect that it's far
more manageable with a few concessions and i've toyed with doing a version
for stock but the loading times are an issue...

Nothing motivates people like money in my experience.

In the everyday world this is probably true (i can't comment, waving dosh
under my nose has never really had an effect) but there was a recent thread running on the Lemon64 message board where most of the active coders there
said that the money wasn't an issue (we all do it pretty much for our own entertainment anyway) and some including myself said they'd actively back *away* from any project where a financial incentive applied extra pressure.
-- ______________________________ _________________________________
/ /\/ ___/ / ___/ / / ___/\
/ Website: www.cosine.org.uk / / /\_/ / /__ / / / / __/\\/
/ ICQ: 44373717 IRC: TMR{C0S} / / /__/ / / / / / / / / /\ /_____________________________/ /_____/_____/_____/__/__/__/_____/ / \_____________________________\/\_____\_____\_____\__\__\__\_____\/TMR


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

uz@spamtrap.musoftware.de (Ullrich von Bassewitz) writes:

I would say the DOOM protagonists are the non programmers. Every C64 >programmer knows about the display resolution and available colors. DOOM with >half the resolution and just 4 colors per character cell - get real! Do you >know how many colors you need just for the shadows and light effects?

Actually, I think the lighting system in Nether works very well in 16
colours, and clever colour selection can overcome some of this. Nevertheless, the colour resolution obviously is the biggest problem.

--
Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Ullrich von Bassewitz" <uz@spamtrap.musoftware.de> wrote in message news:8fh1vb.qc4.ln@news.musoftware.de...

Leo <commodore128@hotmailspamtrap.com> wrote:

This game is
possible! It may not be everything the ibm PC port is but it IS possible.Just because it hasnt been done before means absolutely

nothing.

Who will buy a SCPU, an IDE64, and pay money for a game that is the same

as a

10 year old PC game, just slower and with a lot worse graphics? Especially

if

much improved versions of this game are available on the net for free?

The nay
sayers are always the ones that cant program but think they know

everything.

I would say the DOOM protagonists are the non programmers. Every C64 programmer knows about the display resolution and available colors. DOOM

with

half the resolution and just 4 colors per character cell - get real! Do

you

know how many colors you need just for the shadows and light effects?

Why not try something that has at least a small chance to get realized?

Like

porting Wolf3D to the C-1?

Regards

Uz

Ullrich, Jason,

I apologize to you both for the way I expressed my feelings yesterday.
Doom is an absolute favourite game of mine and of course the C64 is an
absolute favourite computer of mine too so I got a little out of control. I heard the so-called "experts" saying it couldnt be done when I *just* know
it can be done regardless of how the final product really looks or feels.
Again I'm sorry for spouting off that way to you both.

Ullrich,
To me, even if the game is black and white and only 1/4 the size of
the screen but looks somewhat like Doom I would be happy. I think nobody expects it to be a clone or even close to a clone.We all know what the C64
can do and what to expect everytime,graphics wise, when you load up a game.

Some of the demos out there are very impressive and I know that you cant
really relate a demo to a working playable version of a game BUT with the
help of a SCPU with 16 mb ram or an IDE64 with its incredible loading times
I cant see why some sort of playable game couldnt be made.I read your
arguments and what comes to my mind is that you are thinking of some highly technical way of displaying the game like it was on a pc. All I am thinking
is even if its black and white or 1 color or slow and jerky and the bad guys look like a steamy pile of you know what, thats ok. This is the C64 we are talking about here after all and I expect the game to be far from PC Doom.As long as a person can differentiate who the bad guy is from the nearby wall, thats where it would start.Look at MooD. For a stock 64 that game is
awesome. If improvements can be made along the way that dont interfere with game play but enhance the look and feel of the game then thats great- if not then thats ok too.

Wolf 3d never caught on at my house.Although it looks like a fun game
somewhat equally playable as Doom, It just doesnt work like Doom did with
its creepy corridors and eerie sounds. I know this aspect will be near impossible to reproduce on the C64 too but thats ok.Digitized sound could be thrown in here and there due to the fact that we are working with a much
faster cpu and ram quantity. As Magervalp showed with his quick and dirty conversions, even if the game was 80x50, but fine tuned of course, this
would be acceptable to me and hopefully alot of others.

I would buy a SCPU to play a C64 or C128 Version of Doom. And just like everything else, Why do we play any games or such on the C64 when there is probably a better version somewhere else? We do it because we like the C64
and these are the games we grew up on. In this case you would be combining
the best of both worlds.


Jason,
I wish I had the ability today to program something decent on the C64.
I know I could learn. How long will it take me? years? decades? Probably. I would be old and grey and Doom would be done 4 times over before I learned enough to do the job.

Ive watched this group for a few years now.Everytime someone comes up with
a challenge, people moan and grown how it cant be done. Then someone does it and you dont hardly hear a thank you. I know in my heart this is another one
of those challenges.

I wish you did have the interest in Doom as you seem to in Myst or other
type games like that. That is what would bring you to the call. Hopefully
out there is a C64 programmer who has a history with Doom and would like to
see it on the C64/128. It would take a strong passion derived from the love
of the game and the love of the C64 to do it. And of course plenty of time
and patience :) Well enough of this crap. Lets get it on! :)

Leo

--
Im looking for Commodore Cartridges! Got any? Check out my tradelist
& Gameboy Advance items for sale at http://www.commodore64.allhell.com



--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

MagerValp <MagerValp@cling.gu.se> wrote:

160x200: MC FLI. Too slow to be usable.

I have to admit that it does look even better than I thought it would. Still bad compared to original DOOM, and even worse compared to Legacy or any other of the improved versions, but at least one can recognize most of the bad guys:-)

Regards


Uz


--
Ullrich von Bassewitz uz@spamtrap.musoftware.de
22:13:23 up 42 days, 6 min, 10 users, load average: 0.00, 0.05, 0.03
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Leo <commodore128@hotmailspamtrap.com> wrote:

I apologize to you both for the way I expressed my feelings yesterday.
Doom is an absolute favourite game of mine and of course the C64 is an absolute favourite computer of mine too so I got a little out of control. I heard the so-called "experts" saying it couldnt be done when I *just* know
it can be done regardless of how the final product really looks or feels. Again I'm sorry for spouting off that way to you both.

No problem. Commenting on a project that may be unrealistic but harmless was
no good idea from my side either.

Regards


Uz


--
Ullrich von Bassewitz uz@spamtrap.musoftware.de
22:17:27 up 42 days, 11 min, 10 users, load average: 0.00, 0.03, 0.01
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Leo <commodore128@hotmailspamtrap.com> wrote:

let jerks like Jason or Ullrich

*PLONK* asshole...

--
-=[]=---iAN CooG/HokutoForce+TWT---=[]=-
Eat shit! 50 million flies can't be wrong .. :)

--- Synchronet 3.18b-Win32 NewsLink 1.113