gbadev.org forum archive

It's show off time again :-)
I've finally got Quake2 properly running on the DS and I thought I'd post a quick (and crappy) YouTube video. I am still getting Q1 pre2 ready, it's just that I wanted to take a break!

Anyway, linky: http://www.youtube.com/watch?v=Tu4VczrZBdQ (will be up in a few mins)

In case you're worried, this is exactly the same kind of performance that I had when I first had Q1's software renderer running on the DS. However, I'm still not confident that similar performance can be obtained with this game - there's just too much strain on the system this time.
This is more of a proof-of-concept, showing that a full-blown game can be run of the extended RAM provided by slot-2 solutions. Yeah, I know all about the 8-bit write problem :-)

Kinda worried about properly working on this game though, as Q1 has pretty much taken my free time for the last five months!

Comments? ;-)

EDIT: YT is STILL processing, so here's a quick few pics:
http://img440.imageshack.us/img440/1963/quake2shot1my7.jpg
http://img463.imageshack.us/img463/8048/quake2shot2ac8.jpg
_________________
Big thanks to everyone who donated for Quake2

Last edited by simonjhall on Mon Mar 26, 2007 11:13 pm; edited 1 time in total

People are going to be begging for Q3A on the PSP.
_________________
Driven from Tilwick by ice storms, couldn't fit in in Flower Bud...

Nintendo DS: With two ARMs, who needs legs?

GOSH!!! That looks absolutely amazing! The speed is the other thing then...
Are you going to make it Opera expansion compatible?
And please, finish Quake 1 first ;) Thumbs up dude! awesome work on both!
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4

Heh. Its not that all he has to fix is the speed... I mean, sure, thats the only thing worng with it now. But you saw the quake pics from the beginning? Thats the software renderer, to get it up to speed hes gotta recode it to work with the DS's hardware... which is why q1 is taking 5 months :P

Commendable work nonetheless!

tepples wrote:

People are going to be begging for Q3A on the PSP.

and HL1 one DS

I would play it, though, for at least minute or two!
_________________
Thanks!
MKDS Friend Code: 511165-679586
MP:H Friend Code: 2105 2377 6896

Yeah... looks extremely cool :D I woulddn't say the performance is bad at all. Just remembers me when I was 1st playing Q2 on my 486. I had to play it with minimum (thumb-sized) screen to have a playable "frame-rate" ;)

You take a break from coding Q1 by coding Q2? If I ever need to hire a programmer, I'll have to keep you in mind.
_________________
I'm a PSP hacker now, but I still <3 DS.

Oh.. by the way if you ever need testers for Q2 - count me in :)

Nice work. Ignoring the Slo-Mo, it looks great, although I guess we have the rebust SW renderer to thank for that.

Still, that reminds me of one problem with switching from SW to HW in Q2: Garish lighting. Being one of the first games to use 3d accel and coloured lighting, it looked like bloody disco half the time. The devs went a little OTT with the fairy lights in Q2 :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

It's... very very impressive !
Don't mind playing Quake 2 in slow res if you can make it run at ~20FPS

HyperHacker wrote:

You take a break from coding Q1 by coding Q2? If I ever need to hire a programmer, I'll have to keep you in mind.

Haha, yeah - that's true! Basically I do this stuff as where I live there is *nothing* to do so I'm just killing time till I move house :-)

Dunno about the eight-meg Opera expansion - it was pretty damn hard getting this to run in 36 megs! Really, the game should only require about half of that (or even less) but the lack of virtual memory means the game is chewing up loads when it shouldn't do. Hell, I can only load one level so far! But I said all the same things when I started Q1 so who knows how it'll work out!

One thing I'm pretty concerned about it the lack of VRAM - 512k isn't enough for Q1 and in Q2 there's gotta be like 5-10x more data which needs to be loaded as a texture!

And yeah, if we get proper Q2 gaming those PSP homebrewers are gonna wanna go one-up on us (like usual) so they will be pretty much forced to make Q3A work! Which I guess I'll have to respond to by porting that too ;-)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

... so they will be pretty much forced to make Q3A work! Which I guess I'll have to respond to by porting that too ;-)

Rofl.. Yeah way to go !! :)

So as I see it the major task for Q2 is getting the bigger textures to work ? Or is polycount an issue in your opinion. Cause if its "only" (yeah I know only does not mean its simple in any way ;) ) textures just choose the path of using lower res textures...

Ah that's just one of the problems.
There are a few issues which could mean it's a bridge too far for the DS. eg,
- the split memory architecture makes things a little tricky if you want performance, as this slot-2 memory is slow
- Q2 likes MMUs, so will need a bit of coaxing to fix that
- the Q1 binary is pretty huge, but Q2 is nearly twice that! That means that all the custom tools which I wrote for Q1 can't really be used as they will inflate the program size even more
- Q2 requires more VRAM than Q1 (and I've already lowered the texture resolution in that)
- I'd imagine the polygon count is higher
- level load times are seriously poor so tiny changes will require a 2-3 minute reboot to test
- I've gotta do all the same little things to Q2 as I did to Q1 - there are *loads* of such things, and that is where I've spent a lot of the time

Need a team of people to help me on this one!

May as well skip Q2 and go straight for Q4 ;-)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Need a team of people to help me on this one!

Maybe Google Code / SVN is the way to go this time ? I am sure people are willing to drop in... :)

dont get too side tracked now! there's alcohol to be had when Q1 is done!
_________________
www.holbrooksfilms.com

www.tdotodotm.com

tepples wrote:

People are going to be begging for Q3A on the PSP.

sooo true. and quake wars, before it's even out. bloody hell, those psp-ers. ;^p

ps: my litte cousine lost her nds (with a ton of games, like multiple nintendogs, nsmb etc) and now she's got a shiny new psp-white. it was my psp-"first time". it's got a really wonderful display - though i missed the touching very badly (had to clean whipe the screen a lot). i still prefer the nds. ;^)

simonjhall wrote:

May as well skip Q2 and go straight for Q4 ;-)

Before the source is released? Impressive...

I think I should mention that on the N64 version of Quake 2, in order to keep the frame rate up, your on-screen weapon was actually a sprite and not a 3D model. That's why the shooting and reloading sequences seemed to be only like 4 frames. :P

N64 games did that a lot. Each coins and the round part of a Bob-omb in Super Mario 64? One quad. A lot of the stuff in Super Smash Bros.? One quad. The trees in Animal Forest (Japan-only; ported to GameCube as Animal Crossing Population Growing) are four quads: one for the trunk and one for each group of leaves.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Yeah, I realize this. I'm VERY good at seeing what's a sprite and what's a 3D model. I just wanted to point this out if simon is puzzling over how Quake II was done on the N64 so well. :P

@simonjhall

- you could ask the one that is creating this other quake project

Great work Simon!

*glares at Sony for not giving the PSP enough RAM*
_________________
http://aaiiee.wordpress.com/

Ta man! :-)
Again, hopefully I can slim it down to 4+16 megs - otherwise it's gonna be pretty much useless.

*glares at Nintendo for giving the DS sweet FA*
:-P
_________________
Big thanks to everyone who donated for Quake2

Wow...what a horner...MelGipson does visit the ds scene :D
ok ok i should stop spaming stuff here.
BTW md2 is from quake 2 right (take care, retoric alert)?
Well the way i found md2 source was damn to lame for nds. PLS contact me and i promiss you we will speed your port up! (cant promiss 60FPS because i dont know how quake 2 worked, but i can promiss you 2x-3x speed ;) )

Its MelGibson with a B ;) Yeah and I'm visiting the DS Scene when I'm not too busy with ruling Hollywood, ya' know :D

Nintendo Maniac 64 wrote:

I think I should mention that on the N64 version of Quake 2, in order to keep the frame rate up, your on-screen weapon was actually a sprite and not a 3D model. That's why the shooting and reloading sequences seemed to be only like 4 frames. :P

The weapon? a 2D sprite? It is SO not!
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4

Mario Kart 64 used this technique extensively: many objects such as bananas, shells, snowmen, crabs etc, as well as even the characters/karts themselves, are 2D images. They made 3D character models, then simply took shots of them from many different angles and used those in the game.
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

Mario Kart 64 used this technique extensively: many objects such as bananas, shells, snowmen, crabs etc, as well as even the characters/karts themselves, are 2D images. They made 3D character models, then simply took shots of them from many different angles and used those in the game.

Oh yeah? Quake 2 weapon is not a sprite / many sprites from several angles.
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4

Either way, who cares?
Changing the weapon from a model to a quad is not gonna make the framerate increase by a factor of thirty.
In Q1 disabling the gun rendering increases the framerate by 0.1fps - honest!

Now overclocking the machine would yield more impressive results!
_________________
Big thanks to everyone who donated for Quake2

Miika wrote:

HyperHacker wrote:

Mario Kart 64 used this technique extensively: many objects such as bananas, shells, snowmen, crabs etc, as well as even the characters/karts themselves, are 2D images. They made 3D character models, then simply took shots of them from many different angles and used those in the game.

Oh yeah? Quake 2 weapon is not a sprite / many sprites from several angles.

I'm talking about the N64 version of Quake II! Here's some proof even:

...

WHAT?!?!

It... it's actually a 3D model, I just checked! Man, was I high on myself when I thought I discovered that the on-screen weapons were sprites or something? XD

Nintendo Maniac 64 wrote:

Miika wrote:

HyperHacker wrote:

Mario Kart 64 used this technique extensively: many objects such as bananas, shells, snowmen, crabs etc, as well as even the characters/karts themselves, are 2D images. They made 3D character models, then simply took shots of them from many different angles and used those in the game.

Oh yeah? Quake 2 weapon is not a sprite / many sprites from several angles.

I'm talking about the N64 version of Quake II! Here's some proof even:

...

WHAT?!?!

It... it's actually a 3D model, I just checked! Man, was I high on myself when I thought I discovered that the on-screen weapons were sprites or something? XD

Yeah, easy to check. Just make it fullscreen (1280x1024) and the weapon is not pixelated or anything. It even partially goes through enemies and stuff :)
They just haven't animated the model better thus it looks like its 4 frames.
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4

1280x1024? Full screen on the N64 is 320x240 pixels or 640x480 pixels depending on the video mode that the game uses.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

@tepples Emulator :)

MelGibson wrote:

@tepples Emulator :)

Backups? Off-topic.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I can only imagine how much work it would be to scale down Quake 2 for the DS, but it would be very cool. So was this made with the original Quake 2 source code or did you use an already stripped down engine like Arq-lite 2? :)

is it possible to decrease the display resolution? I.e. on gba one could have a surface, use software renderer and stretch a small box across the whole screen. But then again, the problem is probably not the display of graphics but the setting up of it.

@ravey - it's the original Q2 sources. Tbh I never even considered that there may be a better implementation out there which I could use! Last time I tried to use another source (PocketQuake), it was a complete waste of time.
And you're right - stripping it down and DS-ifying it is gonna be quite a lot of effort. I may as well just write off 2007 in terms of free time if I start working on this game!

@ant6n - obviously doing that ain't gonna make it hit 60fps, but I think it could definately be worth a try! May have to have a go later... And if I disable texture maps it normally doubles in speed too... Good thinking, Batman!

For those who are wondering why this game on your 66MHz DS is getting owned in terms of performance against your Pentium 1 @ 66, it's due to the lack of a floating-point unit. If Nintendo had equipped the DS with a math co-pro the game would run at least ten times faster than this.
Y'know - just for kicks I'm gonna compile whetstone for the DS just to see what result I get ;-)

EDIT: for those interested, a 45-second run on my 2.4GHz A64 gives 2222 million (double) whetstones. A 42 second run on my 66MHz DS gives 7.1 million (double) whetstones.
Surprisingly higher than I expected...
_________________
Big thanks to everyone who donated for Quake2

let's hope you can reuse some of the floating point code

Ravey wrote:

I can only imagine how much work it would be to scale down Quake 2 for the DS, but it would be very cool. So was this made with the original Quake 2 source code or did you use an already stripped down engine like Arq-lite 2? :)

Thanks very much for name-checking Arq-lite 2! I never knew that existed.

I wonder if its memory footprint is low enough to fit in 24 MB...
_________________
http://aaiiee.wordpress.com/

tepples wrote:

MelGibson wrote:

@tepples Emulator :)

Backups? Off-topic.

No, he meant that on emulators you can use higher resolutions that doesn't look crappy in 3D. Like this:
[Images not permitted - Click here to view it]
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4

Last edited by Miika on Sat Mar 31, 2007 3:10 am; edited 1 time in total

Miika wrote:

tepples wrote:

MelGibson wrote:

@tepples Emulator :)

Backups? Off-topic.

No, he meant that on emulators you can use higher resolutions that doesn't look crappy in 3D. Like this:
http://bildr.no/image/51507.jpeg

How is 150x120 higher resolution?

chuckstudios wrote:

Miika wrote:

tepples wrote:

MelGibson wrote:

@tepples Emulator :)

Backups? Off-topic.

No, he meant that on emulators you can use higher resolutions that doesn't look crappy in 3D. Like this:
http://bildr.no/image/51507.jpeg

How is 150x120 higher resolution?

Bah, change the "thumb" in your address bar to "image".
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4

simonjhall wrote:

@ravey - it's the original Q2 sources. Tbh I never even considered that there may be a better implementation out there which I could use! Last time I tried to use another source (PocketQuake), it was a complete waste of time.

actually you can take a look at http://jdolan.dyndns.org/trac/wiki/Quetoo

Quote:

* Dramatic performance increases through proper removal of dynamic lighting, polyblend and other "candy" features.
* Integrated video refresh and renderer core simplifies program design and execution.
* R1Q2 Protocol 35 support and Quetoo-specific protocol extensions to save bandwidth.
* Support for asynchronous video/sound/input and network framing: run at 90fps over a dialup connection.
* High color Targa (.tga) image support for all game media.
* Location (.loc) file support for alerting team members to your position.
* Mono (white) lightmap interpolation mode for neutral (non-colored) lighting.
* Bright player skins supported directly within the engine.
* Ability to disable ambient sounds and load wildcard pakfiles (*.pak).
* Vastly improved console with Bash-style tab completion, positioned editing, mwheel scrolling, etc..
* Optional deathmatch mod with MySQL frag logging and team play.
* GNU Autoconf/Automake build scripts and pure C source compiles cleanly with modern gcc.

Miika wrote:

tepples wrote:

MelGibson wrote:

@tepples Emulator :)

Backups? Off-topic.

No, he meant that on emulators you can use higher resolutions that doesn't look crappy in 3D. Like this:
[Images not permitted - Click here to view it]

But how can you load a commercial game into an emulator to make a screenshot after the date the new rules were posted without using a backup, which is off-topic?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

You can't. But come to think of it, we weren't until you objected.
_________________

dualscreenman wrote:

What about Gaim DS? Gaim pretty much has support for all IM programs.

tepples wrote:

"Goshdammit, the DS is not a Gaim-boy! It's a third pillar!"

tepples wrote:

Miika wrote:

tepples wrote:

MelGibson wrote:

@tepples Emulator :)

Backups? Off-topic.

No, he meant that on emulators you can use higher resolutions that doesn't look crappy in 3D. Like this:
[Images not permitted - Click here to view it]

But how can you load a commercial game into an emulator to make a screenshot after the date the new rules were posted without using a backup, which is off-topic?

I don't know what the hell you are talking about, but yeah sounds off-topic.
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4

Yeah.. sorry seems all to be my fault :(

Well done Simon!

Yeah its a shame the ds isnt just a bit faster, hahaha.

Hmm, Maybe the DS2 we will all be kicking each others asses at Quake3

Yeah man, I know! DS2 will pwn some ass. Now if only they got rid of the second screen, cranked it up to 333MHz, gave it eight times the RAM, an FPU and a fantastic vector processor then Quake3 would be *awesome* ;-)

Though seriously, if a manufacturer brought out a slot-2 card with 64 megs of banked RAM then I would definately have a go at getting Q3A running. How hard could it be?!

In fact, if everybody bombarded the card manufacturers with a mail asking for such a solution there's a chance that it would get made...
_________________
Big thanks to everyone who donated for Quake2

"Now if only they got rid of the second screen" Nooo! Get a PSP. ;)

Sunray wrote:

"Now if only they got rid of the second screen" Nooo! Get a PSP. ;)

I think that's what he was getting at! ;-)

Incidentally, fitting Q3 on the PSP is presumably harder than fitting Q2 on it, a project which as far as I can tell has been abandoned.

Maybe if we got to use all of the 32MB?
_________________
http://aaiiee.wordpress.com/

Dreamcast, with 16 MB RAM + 8 MB VRAM, ran Q3A.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Dreamcast, with 16 MB RAM + 8 MB VRAM, ran Q3A.

Or at least a game which looked like Q3A. Goodness knows how much of the original code or assets were reused in the conversion.

I'm not saying it's impossible to get a game on the PSP or DS which looks and plays like Q3, but it would take a lot of time to work the original code into shape.

Anyway, I'm going off topic here.
_________________
http://aaiiee.wordpress.com/

quake 3 did run on the dreamcast, if you downgraded the PC version you could play multiplayer

This is probably fairly irrelevant, but you had to have a special set of maps on the server for the PC version to work with the dreamcast version.

I do remember that these maps contained "special modifications" for the Dreamcast and a few exclusive maps designed for splitscreen play. I don't know if they reduced poly counts or anything else with these maps, but you do have to have them if you intend to play vs a dreamcast client.

The dreamcast q3 maps had lower detail than those from the original. When it comes to polycount and other media usage q3 is quite a jump from q2 being the first iD game to rely exclusively on graphics accelerators for rendering.

uhm.. just out of curiosity, is this game still being worked on? you seem kind of half enthusiastic about it, and you seem to be tired of working on Q1 - all of which are understandable. I have no patients for coding and such, myself.

but, yeah, is there any status on this port? is it go, or no?

cheers, good sir!
_________________
-01011101001010101010 (frank)

No...
I've been really busy recently - I am a programmer 9-5 as well! - and haven't had too much time for Q1. Plus I was never gonna work on both games at the same time. Once Q1 is finished (getting closer every day) I'll see what's required for Q2.
But yeah, you're right - I'm pretty sick of these games!
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

No...
I've been really busy recently - I am a programmer 9-5 as well! - and haven't had too much time for Q1. Plus I was never gonna work on both games at the same time. Once Q1 is finished (getting closer every day) I'll see what's required for Q2.
But yeah, you're right - I'm pretty sick of these games!

You should really dip your head into finding out how Ad-Hoc connections are made. Seriously, I believe that you can do it. You are the one. ;)
_________________
http://licklick.wordpress.com

No, he should bring peace to the middle east and/or order to the matrix! He's the one(s)!

I think I'll pop all those things on my 'to do' list, below 'buy some milk' ;-)
But no, I did seriously consider doing the ad-hoc thang when I added networking support into Q1. I'd love to have a go again, but I felt like I should get SOME networking into Quake before spending a month reverse engineering ad-hoc!

Ok, my new to-do list:
- finish Quake
- do ad-hoc
- do QuakeWorld
- do Quake 2
- have breakdown
- buy milk.

Oh and do my job too!
_________________
Big thanks to everyone who donated for Quake2

Water > milk.
_________________
http://licklick.wordpress.com

not combined with breakfast cereal it don't!
_________________
Big thanks to everyone who donated for Quake2

i just like 4 multiplayer games

QUAKE 2, Duke 3d, Unreal Tournament and Counter Strike !!!

If you can make Q2 runs nice on DS you will be a Hero!
_________________
http://flickr.com/photos/stuffbox

Well again, we'll have to see. Don't expect to be playing Q2 on your DS before Christmas though!
Oh and just for chuckles: I got a message on the Q2 youtube vid page yesterday asking if I could do Halo for the DS. Discuss. ;-)

But yeah I think I will have a look again at the ad-hoc stuff as I think there are enough DSes, wireless hardware and homebrew in this house to make it work!
_________________
Big thanks to everyone who donated for Quake2

Get Halo on DS and I'll love you XD, also considering I own halo pc i get get what i need....

Microsoft's not gonna do it, but someone did put Halo 2 (of sorts) on GBA.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Here tepples:
http://pinocchio.jk0.org/halo2/
Halo 2 for GBA

God money I'll do anything for you...

This is an early demo of Halo 2 for NIИTENDO's Game Boy Advance handheld video game system. It was leaked to me by one Gus Nomeles, who alleges that all of Halo 2 is in this ROM. It seems to have pretty good anti-emulator protection, as it doesn't run at all in No$gba, and it slows down and clicks in VisualBoyAdvance.

10.3mb

LoL this is horrible I took a youtube vid of me playing it(This no Halo whatsoever and is not worth d/ling a 10mb file):
http://www.youtube.com/watch?v=wXke-ZzNnLE

Protip: http://pinocchio.jk0.org is Tepples' own site, or at least one of his older ones. That Youtube video is hilarious though. I'm tempted to download the file just to see how much of it is empty/random data.

EDIT: nevermind, I see it's a GSM with a demo game, which explains why it didn't compress too well in the zipped file.

Masterofdarkness wrote:

Get Halo on DS and I'll love you XD, also considering I own halo pc i get get what i need....

nonono, after quake comes HL, which is, of course, the best fps of all times

Fine I'll go with that,thats just as good :) And I have that cd too :)

simonjhall wrote:

Ok, my new to-do list:
- finish Quake
- do ad-hoc
- do QuakeWorld
- do Quake 2
- have breakdown
- buy milk.

Oh and do my job too!

Whoo! Ad-hoc AND QuakeWorld?? You've got me very excited... Seriously if you hadn't have been doing this port I wouldn't have gotten my Supercard.
Are you planning on doing some kind of ad-hoc lib or just coding it into quake? Or both? (code into quake then make a library...) Personally the only thing I care about having ad-hoc at the moment is Quake :P Not to mention ad-hoc would put your port leagues above the 'other' one...

Speaking of which... what do you do for work?

dantheman wrote:

Protip: http://pinocchio.jk0.org is Tepples' own site, or at least one of his older ones.

Correct. This is the site that hosts my avatars and other stuff that I toss up for forum users but don't find worthy of a full release on pineight.com. For instance, lu and lj lived there until I started distributing them as free software. (And yes, LJ fans, that's the same Gus.)

Quote:

nevermind, I see it's a GSM with a demo game

See the explanation of the "halo 2" name and backward N in NIИTENDO, after which you will understand why I bragged on Bemanistyle about running Halo 2 on my PlayStation. And it is this demo that led directly to the development of Luminesweeper, proving that gameplay can coexist with GSM 06.10 soundtrack.

Now back to Quake II, the game after the game that featured an NIИ soundtrack. Turn your head 90 degrees to the RIGHT:
?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

€

Awesome! I was like - "how is turning my head going to change anything? Oh, right!"

And I still don't know if I can be arsed with QW. I might just do a Rockstar Games and go from GTA to Table Tennis ;-)
_________________
Big thanks to everyone who donated for Quake2

Tepples I don't there is a click sound, That's supposed to be shooting of guns....
http://www.youtube.com/watch?v=-UzcnjGsXo4
different one you need to turn your sound loud-_-

On Topic: It would be great playing Quake 2 with friends!

Impressive work. Can't wait till this gets optimized some.

@Masterofdarkness: That would be so awesome.

Ok, just an update on this (dunno why I'm doing this!)
Thought I'd get off my arse this weekend and check out the Q2 code on my PC. I've not done a lot of work on it in the last six months, besides fix the load times. They were so slow that working on it is completely unproductive, as you've gotta sit around and surf the net for three minutes until you can get it to crash again!

Anyway, here's some info for those who care
- the game now takes about a minute to load (once the program has started)
- the world is now rendered with the DS' 3D hardware; the framerate looks very playable
- I'm an inch away from getting texturing in
- no models, GUI, etc
- the proper palettes are in (hence I can now nearly texture), as are the game fonts
- I've got the RAM usage down to a pretty low level. The existing system required an MMU and (virtually) allocated memory in a crazy way. One problem I had before I sorted this out was that I could *just* squeeze a demo into 32 + 4 megs. After looking into it I realised that 70% of that memory was actually going to waste! The *demos* ought to run in ~10 meg of RAM now.
- it's 8-bit write hell, and I'm gonna have to go strb hunting to sort that out!

No promises, but there's a chance I may actually work on this properly :-)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

- it's 8-bit write hell, and I'm gonna have to go strb hunting to sort that out!

I don't know if it'll help but what I did to hunt down 8bit writes was modify desmume to write a warning to the console and exit.

Then I'd take the address written out and use it with arm-eabi-addr2line to find the source :)

No idea if it supports external ram though and it's damn slow.

Lazy1 wrote:

I don't know if it'll help but what I did to hunt down 8bit writes was modify desmume to write a warning to the console and exit.

Or just have gcc output assembly sources and grep for the right instructions.

Hmm...the porting effort is progressing fast. In just a handful of evenings I've managed to get half the game's graphics onto the 3D hardware. This took me weeks, if not months to do before!
- the world is now rendered correctly, no graphical errors
- buttons, lifts, moving walls etc are all in
- no models, or GUI
- all brush model texturing is done correctly
- vertex lighting (a la QDS 1) is in, and looks ok
- every main level I've tried seems to load, with ample RAM spare (via a slot-2 card)
- in-game frame rate is pretty shit, however demos run at ~15 fps whilst using mega floating-point code, no optimisation
- poly limit seems ok-ish, however I've not got any models in yet...
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Hmm...the porting effort is progressing fast. In just a handful of evenings I've managed to get half the game's graphics onto the 3D hardware. This took me weeks, if not months to do before!

Though it's nothing special by today's stadards, I grew up on Quake2 and was amazed by the graphics at the time - 3dfx was just becoming popular (at least where I lived) - and it was amazing for it's time with nice smooth graphics and excellent gameplay.

Even more amazing is that you've somehow managed to squeeze most of that goodness, that used to only run on 'top of the line PCs' into a device the size of my wallet.

In case nobody has said it lately, thank you for the amazing contributions you make to the DS homebrew community!

If there was such a thing, you'd have my vote for the 'coolest guy I don't know on the internet' award.

I'm still having hard time to believe this is actually happening. Simon, you really think that Q2 could be squeezed into DS?

If so, I'm sending you my sister ASAP (I mean I would, if I had one ;] )

Well if you think about it, id did manage to port it to the N64. It's not out of realm of possibility that it could happen, but to suddenly happen so fast is amazing and a testament to Simon's coding skill and to what he's learned from QuakeDS. Awesome work!
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

Please send any sisters through the donation link in the sig <considers making slot-1/2/RAM jokes, no...>

And no I'm not sure if the DS can handle this, as I'm disappointed by the in-game performance. I can't remember if this original game was like this, so can't really compare with this game... On the flip side Q2 doesn't seem to have the massively inefficient VM that the Q1 has, so you can expect a cosy 10ms/frame back :-)
Also I've still not decided whether I'm actually gonna go to town on it, like the other game. I don't really wanna spend another year reverse-engineering code...

PS: can this thread get moved to the development forum?
_________________
Big thanks to everyone who donated for Quake2

Did a load of Q2 today, and I've decided to make a quick video (with me actually playing it) and stick it up your youtube, in order to show those "OMG 1fps!!1112" naysayers that the Quake2 on the DS is a very real possibility.
So anyway, here's me buzzing around the entry level. It's surprisingly hard to make a video of the DS, as well as use it at the same time :-)
The reason I never actually shoot the bad guys is cos I can't reach the L shoulder button due to the makeshift camera mount I made!

The framerate is still crap, but this time it's not due to the software renderer taking all the cycles. This time all the rendering's on the GPU, but the CPU hog is all the floating-point code used to set up the rendering.
Also the white pop-in is when the game runs out of VRAM and some new textures need to load in, so something has to be freed.

http://www.youtube.com/watch?v=Gt9jOEbHm_4
And here's a few pictures (much sharper)
http://img511.imageshack.us/img511/1867/imgp0702vh6.jpg
http://img135.imageshack.us/img135/7731/imgp0703fe8.jpg

Comments?
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Comments?

One: A.W.E.S.O.M.E

Wow - simply great...

Good job.

Does a white object mean the texture hasn't loaded yet? If so, I could suggest a simple way to hide this.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

That looks amazing, very impressive.

The fact that it runs this well without floating point code optimizations is EXTREMELY impressive! Hell, the fact you even have it running is!

Very exciting stuff. Maybe we'll see something of it, maybe not; either way, you're still the man with DS coding :)

Blimey. That's awesome. Lovin' your work Simon.
I can't believe you have Quake 2 running so well on the DS. That's some achievement.
I presume you are using the M3/EZ 3 in 1 ram pack combo?

tepples wrote:

Does a white object mean the texture hasn't loaded yet? If so, I could suggest a simple way to hide this.

Yeah, and the same problem exist in QuakeDS. I had a plan for hiding this by averaging all texels in a texture at load-time. This would unfortunately increase the loading-times a bit, but it would make the missing textures less annoying as a constant color could be used instead of a white color. Perhaps the result for one BSP-file could be cached and stored to disk?

kusma wrote:

tepples wrote:

Does a white object mean the texture hasn't loaded yet? If so, I could suggest a simple way to hide this.

Yeah, and the same problem exist in QuakeDS. I had a plan for hiding this by averaging all texels in a texture at load-time. This would unfortunately increase the loading-times a bit, but it would make the missing textures less annoying as a constant color could be used instead of a white color. Perhaps the result for one BSP-file could be cached and stored to disk?

That's close to what I was planning to suggest.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Or, since everything is kind of gray/brown/bronze anyway, just arbitrarily picking one of those and making everything the same color would be less noticeable than white. The original Quake was very similar as well.

I must say I'm very impressed. Fantastic work and indeed quite playable even without the optimizations. And it looks great too! It's actually running better than I remember it on some old PCs I've seen (granted, I keep remembering an old 486 laughably trying to run it, which was about the same as the original QuakeDS 2 preview). This really gives me high hopes that it's possible to run on the DS.

Now, my primary concern is how to actually play the game. In the original, you just had to worry about moving, aiming, shooting, jumping, and weapon switching. All can be handled pretty well with the DS. However, now add in crouching, swimming, item/inventory control and activation, and jetpack support, and things get quite a bit more complicated for a handheld that's already pretty maximized in input utilization. This will certainly be interesting to see how much can actually work. But of course, I'm jumping ahead a bit. :D
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

Has anyone had a go with Q2 on the PSP? How does the button layout work on that?
_________________
Big thanks to everyone who donated for Quake2

Jump: double tap top third of screen
Use: double tap middle third of screen
Crouch: double tap bottom third of screen; do it again to come out of crouch.
Really nice Youtube video by the way!
Shoot: L trigger
Inventory: R trigger, tap on items on touch screen
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

I can't tell you how many levels of "ewww" that is to me. Double-tapping the touchscreen for anything equates to fail in my book, let alone 3 separate controls in 3 different positions of the screen that may not be easily distinguished between. Good luck trying to pull that off in a firefight. I won't go into detail how much I hate jumping in Metroid Prime Hunters, other than to say it always throws my aim off.

Here's my go at it:
L: Fire
R: Jump
A: Change weapon up
B: Change weapon down
X: Select item
Y: Use item
Double-tap screen: Crouch

Since crouching isn't as important as most other functions, the only place I could think of putting it was on the touch screen. Even if it was made as a toggle button, you still need it for swimming up and down and changing elevation with a jetpack. The only open solution is the touch screen, unless you want to take your hand away from aiming to do it.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

MechaBouncer wrote:

I won't go into detail how much I hate jumping in Metroid Prime Hunters, other than to say it always throws my aim off.

How much does jumping, swimming, or even running throw your aim off in real life?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

MechaBouncer wrote:

I can't tell you how many levels of "ewww" that is to me. Double-tapping the touchscreen for anything equates to fail in my book, let alone 3 separate controls in 3 different positions of the screen that may not be easily distinguished between. Good luck trying to pull that off in a firefight. I won't go into detail how much I hate jumping in Metroid Prime Hunters, other than to say it always throws my aim off.

Imho Metroid's controls are the only way to fly when doing stylus-mouselook. I don't know about you, but for me holding the stylus incapacitates me from using the ABXY and R buttons. So for QuakeDS it was a choice between mouselook or having multiple buttons, as I couldn't find any options for tapping and doubletapping the stylus in the configuration, so I went with ditching stylus-mouselook and just using L and R for strafing, A for freelook (using the D-pad), B for fire, X for change weapon and Y for jump. I can't really pull off more than normal difficulty though, as it's a bit like playing an FPS on a console (Metroid and Halo players will feel my pain).

Jumping with R throws off my aim because I have to reach around to hit the R button with my pinky because I'm holding the stylus.
_________________

dualscreenman wrote:

What about Gaim DS? Gaim pretty much has support for all IM programs.

tepples wrote:

"Goshdammit, the DS is not a Gaim-boy! It's a third pillar!"

Seeing that nothing makes everyone happy, I at least hope all functions are mappable like how QuakeDS already is (save for double-tapping the screen, unless I missed that). Which is something that MPH definitely failed at. Presets just aren't enough.

As for binding functions to the face buttons, I suggested that because they're functions that are less important so that you can momentarily take a pause from aiming to press them and get back to firing. You still have the ability to run as well. I find it better than cluttering up the touch screen even more.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

There's also the F1 key to sort out, to stop the damn thing saying "computer, update" over and over again ;-)
I've not actually looked at sound support yet, but I really really hope it's similar to Q1 so I can just drop in that sound system I wrote...
_________________
Big thanks to everyone who donated for Quake2

That calls for a "Please mash the touch screen with your palm to read" message. XD

In all seriousness, it may require something like Select to be used. Which would also require menu navigation to be tweaked from how it's currently implemented on QuakeDS to using something like A for accept and B for cancel. Start could still bring it up, though (maybe even pause the game as well). Otherwise, one of the other buttons will probably have to pull double duty. Just a thought.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

MechaBouncer wrote:

That calls for a "Please mash the touch screen with your palm to read" message. XD

Or they could set it up so that the player reads messages by looking at his feet, in which case an arm with a watch comes from the left side of the screen.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I hadn't considered it automatically showing up on the touch screen. That may be the best option anyway.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

For the people talking about the controls, saying that R is hard to hit when using the touch screen. This might help http://www.thylus.com/, since it's only the tip of your thumb you'd still have the base of your thumb to hit the a/b/x/y buttons too. I plan on getting one, not sure how great it will be but its only 6 bucks so you really can't go wrong.

Why not using double-tap jumping like Metroid?

Because there are those of us out there that despise double tapping a touch screen for an important function like jumping. In the Quake days, jumping is how you dodge (not to mention rocket jumping). It seems to be forgotten in a lot of games as of late and considered an afterthought. Here are the reasons I hate double tapping the touch screen to jump:

1. It's more difficult than just pressing a button. Lifting the stylus and dropping it back down again is a more complex movement, and one I find quite unnatural. This added complexity results in it taking longer than just pressing a button. The same goes for repeated jumps, where it just compounds the problem (just try bunny hopping with it).

2. It throws my aim off every time I do it. Because you have to lift the stylus away from aiming and tap it back down, I effectively can't aim at all through the time it takes to perform the jump. Then I have to recover my aim to fire again. However, if I am trying to dodge, this pretty much means I can't do anything else because all effort will be in trying to jump instead.

3. It's unreliable. The detection isn't perfect, and while it's okay enough to do it when you want to, it's even easier to do it when you don't want to. With the frantic pace of a FPS game, you're aiming all over the place. I can't tell you how many times I've tried to quickly aim at something else, only to jump.

I'm not saying using a button is perfect, either. As pointed out, it's also difficult to use the R button to jump by curling my pinky around it (I have small hands), but it does allow you to jump and aim at the same time. It also helps that I bought an extending metal stylus that adds another .75" to it. The Thylus sounds like a cool idea as well, but I wonder if it would interfere with using the thumb for pressing buttons. Ideally, I wish the DS had additional second L2 and R2 buttons (and the PSP for that matter), but that's not going to happen. Hell, even a single touch screen "Jump" button would be more effective than double tapping. At least then it's a simpler action and more reliable.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

Quote:

I can't tell you how many times I've tried to quickly aim at something else, only to jump.

I can tell you how many times I have. Absolute zero. Another possible solution is to use buttons in the corners of the screen that can be reassigned. They would be really, really small buttons and would only activate if the stylus were to touch down and touch up on them. I'm sorry, but the R button is truly impossible to hit without using a stylus that doesn't fit in the DS. The thumbstrap that was supplied with the DS Phat was good for this, but the DS Lite didn't have one.
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

Which is why I bought a cheap metal stylus that is the same size as the DS Lite's normally (so it fits in place perfectly), but will extend .75" longer. It works pretty well. I was able to get a 4 pack (one of each color) for less than $4 USD. Cheap, effective, and pretty durable too. I also took the thumbstrap off my old DS and put it on my Lite, but it doesn't work very well because of the short strap, large and imprecise surface when trying to press small touch buttons, and it interferes with pressing the ABXY buttons with my thumb. The Thylus would be more effective for most cases.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

The non-Nintendo stilii are usually made out of hard plastic with a sharp tip, which scratched my DS Phat screen to the point that it wasn't accepted for a trade-in.
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

another solution could be double-pressing the up button.

It won't hurt the aim at all, though it's a bit unnatural, but easy to do.

The real solution would be to allow user-defined configuration, so you can chosse, double-tapping, R button or whatever you want and everyone is happy :)

Something like that was done on Goldeneye. It was a painful experience trying to go into a crouch and walking backwards. You never knew which it would try and do.
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

I personally hate the tapping, since it's really hard to get right when coding it and I'd only get complaints like "you've done it wrong!" etc. No way, Jose. I also think it's hard to aim and do other stuff, and feel like I'm not in control when playing...
_________________
Big thanks to everyone who donated for Quake2

Have you considered compressing the textures or reducing their color depth?
Is that even possible?

I'm gonna drop the texture res. It's really easy to do for the world textures, but a bit harder to do for the model ones. I already do it for Q1 (since it has similar VRAM requirements) and nobody has complained that the models have half the texture resolution :-)
Q1 has a roughly 30/70 split between world textures and model textures. Q2 has a different skin depending on how shot-up a model is, so I expect it to be even worse. This swapping in and out of skins really fragments texture memory, so I may have to dig out the ol' VRAM de-fragger...
_________________
Big thanks to everyone who donated for Quake2

Is that something that's done at load, then? Considering it uses all the original game files and textures, as well as those for any mods or player skins. I can only imaging it gets scaled before being loaded into RAM. And as for swapping textures, since the texture should occupy the same amount of space for the same model, is it possible to just replace the one in VRAM at the same address, or does it not work that way?
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

What happens if you still want to render another model with the original skin? ;-)
And yeah rescaling is done on load, and it's surprisingly fast.
_________________
Big thanks to everyone who donated for Quake2

that said, if you need some tester for a new quake1 version or for quake2 i'm still up :) i have the pak files for quake 1 and i should be able to find where is laid my old quake2 cd...

Happy to test anything you put out -

DSLite - R4 - 32MB Supercard & Retail CDs for Q1 & Q2

Lots of time to kill so I can provide meaningful QA and feedback. Just PM.

As always, much respect for your work.

Oh, dur. Totally forgot about that. So you ideally would want to load all different texture versions in at the same time? How big are these changing textures, typically? I'm guessing the fragmentation occurs because there isn't enough room to just load them all for the particular models. And I didn't realize that the DS had such weirdly sized VRAM banks until I looked it up. Although, are only the first 4 banks (512KB total) available for textures? I guess that would further limit it. Sorry, I'm just really curious about this.

If it really comes down to it and there are no other options, I don't think I'd have a problem with it not changing the textures to the battle-damaged versions. The fact that the game runs on the DS at all is the best part.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

One phat post about texture management:

If you ever had a go with the first release of Q1 you may remember that the models were pink, but the rest of the world was textured? The reason for this is that the world and brush model textures can relatively easily be loaded and fit into the DS VRAM (banks ABCD are used), and it's even easier to get working since the textures are already MIP'ed - so if there are too many textures for a level, the next quality level down can just be loaded. The textures were loaded when the level was loaded.
The model textures added a world of problems, which was why I waited quite a while to get them into the game. They're pretty big, they have odd sizes, they sometimes use transparencies and models can have more than one 'skin' (for instance there is one armour model, but it has ~3 skins, one for each type of armour pickup) and models can also have animated skins! Complicated...

Since there could be any number of different models in a level (each with different texture requirements) it is not feasible to load in the textures when the level is loaded. With Q1 I could load only 2-3 full-res skins along with a level's worth of half-res world textures. Each of the 10 ish gun models have a texture, there are 5-10 types of pickup and about 5-10 different types of bad guy. That's a lot of textures!

So the solution I came up with was to register a texture's details when the relavent model or world surface was loaded (when the level changes), instead of actually loading the texture into memory. Details would include what type of texture it was (from RAM, from disk, or always resident (like the crosshair)), where it could be found (RAM address or seek pos within a file + file handle), sizes and transparency details.

When the relavent model is rendered it tries to bind the texture the game says should be used. If it's resident in memory the GPU will be told to bind that texture, if not some 'other' action is performed (I turn off texturing and set it white) and the request for that texture is flagged. When it comes to the end of the frame it checks to see if any texture loads were requested and those textures are loaded during the really short window where you can play with VRAM without making the screen flicker. The next time that model is rendered (probably the next frame) the texture can be bound properly as it's already in memory and the object gets textured correctly.

However if there is insufficient VRAM available to load a texture then an old one gets discarded and the new one gets slotted in its place. This can lead to fragmentation of the texture memory which is why you can see the Q2 vid I posted flashing white a few times since lots of textures were flushed at once. This 'flushing old textures' scheme works pretty well since the textures that are normally dropped are the textures for the parts of the world that you can no longer see.

The sound system also has a similar setup. Only the most recent ones are kept in the tiny cache managed by the ARM7 and old sounds get dropped so new ones can be loaded in.

Finally, the cool thing about managing constrained systems like this is that you can defrag the memory in the background when the system is idle. So say it's vblank time and there are no textures to load - texture data can be moved around to reduce fragmentation...

You did ask how it works :-)
_________________
Big thanks to everyone who donated for Quake2

Thank you very much. Quite informative. And a pretty ingenuitive texture caching since it still chugs along even if the texture is absent. :)

Too bad the DS doesn't feature texture compression or anything like that. I guess the only thing that can be done is dropping the resolution. To be honest, I had no idea you were doing that on QuakeDS. It's so small to begin with that I don't think people would really notice. Perhaps you could reduce them further?
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

There is texture compression and I looked into it a bit, but there seem to be some restrictions on how it's used. Plus when would the compression be done? It'd have to be done on a computer first and people would have to remake their pak files etc. I'd have to write a tool for this to happen and I'd then get loads of support emails :-)

But yeah Q2 is currently using full-res textures everywhere, hence the VRAM swapping! They're compressed in PCX format so I'll have to decompress them before down-scaling them which is something I don't think there will be enough to do in the tiny gap after the vblank... I'll have to do it at load time (and keep the textures resident in main memory) or something... Grr...
_________________
Big thanks to everyone who donated for Quake2

MechaBouncer wrote:

Too bad the DS doesn't feature texture compression or anything like that.

It does. Hardware LZ77 decompression. But the texture needs to be already compressed of course, and since QuakeDS uses standard quake files to load, the resulting textures are uncompressed (or at least not compressed in the format that the DS hardware eats). Compressing those realtime on the DS just for the sake of having more VRAM space would probably just slow things down terribly. For Quake2DS, it might be an idea to do some preprocessing on a PC to create a DS-optimised PAKfile with compressed and/or resized textures, precompiled models and such.

Edit: it seems Simon beat me to it and wrote pretty much exactly what I wrote :)

Preprocessing the game files would be a great idea, if people can't follow instructions then they just won't be able to play :)

Even if you don't compress the textures you could always use a different format than PCX to get around the problem you mentioned.

I agree that a separate utility would be ideal for addressing a lot of problems. Otherwise, it sounds like Q2DS may require external RAM, then? I think I'd still opt for a texture re-pak-er in that event. Then people don't need to get extra hardware. We were doing DLDI patching for ages, this isn't much different. I guess the main question boils down to which you think would be easier and more effective. :)
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

MechaBouncer wrote:

Otherwise, it sounds like Q2DS may require external RAM, then?

Quake2 already requires EXRAM, and there's pretty much no way around that.

What you could do is make a texture conversion utility that runs on a DS, in the background, while the user plays some silly 2D puzzle game or something.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

LOL
However, that's not as bad an idea as it sounds - you could totally compress stuff during the dead time at the end of the vblank. Or it could just be done by the ARM7. When it's compressed the old one is removed and the new smaller one is inserted in its place.
(I'm sure there are restrictions on where compressed textures are placed though)
_________________
Big thanks to everyone who donated for Quake2

Since you'll have to hold everything in RAM anyway in order to shrink the textures like you mentioned earlier, do you think they could not only be shrunk in resolution, but also be in LZ77 compressed format? Or are you now talking about converting the textures in-game and writing them back to the card so that they're permanently changed? And by restrictions on where it can be placed, do you mean like only certain VRAM banks can handle them or something like that?
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

If you were to use the compressed texture format you've also got to use special palettes, and they need to go in certain places in VRAM and I seem to remember that you need to change one of the banks in the middle of A-D to hold this palette information. Sounds like a lot of lost VRAM as well as a big gap, preventing you from having textures which cross the banks.
Sounds like too much work... I'm just gonna lower the res a bit, and it'll be fine I think!
_________________
Big thanks to everyone who donated for Quake2

You could have Quake II require the user to import pak files before they are played. When they're imported you can convert the data to a more DS friendly format. This could be an optional feature to improve performance -- just fall back to the unprocessed data when the user hasn't imported it.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

If you have objects whose sizes are all a power of two, isn't it possible to use a buddy heap to fit them all without crossing bank boundaries? Or is there something fundamental about the VRAM allocator that I don't understand?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

The majority of the textures in the game aren't power of two...
The texture allocator will work fine with a 'gap' in the memory.

Oh and after a quick look at gbatek (where did that guy get all that information?!) it seems that compressed textures can go in banks A and C, with B being used as palettes. Or have I misunderstood it (likely!)?
_________________
Big thanks to everyone who donated for Quake2

could it be? and im just spitballing, that what you REALLY need is... some better hardware? 4mb onboard ram?! were they nuts?! the battery life wouldnt have suffered THAT much with a paltry 16mb would it?
_________________
NDSL: M3Real, EZ4 Lite Deluxe, 2x Kingston 1GB Micro SD, 1x Kingston 4GB Micro HCSD 1x Kingston 8GB Micro HCSD

It is a tiny amount of RAM :0

However, I could see that if they were to increase the amount of memory they might also want to increase the memory bandwidth too. As it stands the programmer can access every byte in memory in ~1/10th of a second. If they were to increase the memory size (without increasing the speed) to say 32 meg it'd take an entire second to access all the memory! They can't encourage developers to use the memory if it'll take a lot of their frame time to actually get a hold of their data (since they now have so much data). Y'know what I mean? They would have to increase the memory bandwidth by a factor of eight to cancel out the slowdown incurred by having eight times as much memory to play with.

Also they'd probably want to increase the data cache size or its associativity to make the cache more effective for the larger memory size. All these things would add up in cost and reduce their profit. And I'm sure the CPUs in the DS cost pennies to make ;-)

Finally, the thousands of games available for the DS so far have shown that 4MB is plenty!

(as another example of the bandwidth thing, it takes me over FIVE SECONDS to walk the RAM in my 32 meg Supercard - that is insanely slow)

EDIT: btw, I am still pushing for an xmas playable demo of Q2DS
_________________
Big thanks to everyone who donated for Quake2

lord_hardware wrote:

the battery life wouldnt have suffered THAT much with a paltry 16mb would it?

But the manufacturing cost probably would have.

Too bad the final production versions weren't like the dev versions with 8MB of RAM. I guess they need more RAM for debugging tools?

But excellent news on trying to have a demo out by Xmas. It must mean things are really progressing well and quickly?
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

simonjhall wrote:

EDIT: btw, I am still pushing for an xmas playable demo of Q2DS

you are my Hero :)

MechaBouncer wrote:

But excellent news on trying to have a demo out by Xmas. It must mean things are really progressing well and quickly?

It'll be a push and a lot of stuff would have to be cut to make the end of the year, I think. The game speed is pretty playable (but pretty poor in places) and a lot of the graphical issues have been sorted out. I've played through the first 3-4 levels and it's ok on a 16 meg card. For now, 8MB isn't enough. I am loading in a lot of extra data though that's not necessary which I could drop to make it work on people who only own the Opera expansion, but I don't think there are enough people to jusify the time.

Anyway the stuff that takes ages and makes all the difference probably won't be doable for xmas. eg
- gui
- hud
- control customisation
- game loading/saving
- runthroughs of the game to see problem areas

I'm gonna aim to ensure that it works on slot-2-only solutions. At the moment it'll only work on a slot 1/2 combo as that's easier. Also there's no sound, and I'd really like to just drop in my Q1 sound system... Hmm...
_________________
Big thanks to everyone who donated for Quake2

Lucky thing I have a 3-in-1, then. Considering what you've said before, I'm not surprised it requires Slot-2 RAM. Is that still using original-sized textures, or is this post-resizing? I'm guessing post-resizing?
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

simonjhall wrote:

Finally, the thousands of games available for the DS so far have shown that 4MB is plenty!

Exactly!

The problem here is not so much that the DS can't handle this kind of thing. Games like Metroid Prime Hunters and so forth more than prove that.

The real problem is that Quake 2 was designed with PC's in mind, not consoles like the DS and hence, off the bat, it's not massively suited towards a DS port.

This doesn't mean a port is impossible, it's just difficult as Simon has shown :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Does anyone remember if the N64 port required the RAM expansion pack? And what else was changed? I would imagine it was running at a resolution of no higher than 640x480 and probably had reduced textures, but I don't know for sure.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

Quake II N64 didn't require the expansion pack but if you had it, there were extra lighting and weapons effects. It had totally different levels to the PC version and Playstation versions.
_________________
GTAMP.com/DS

Well what about the PlayStation version? I wasn't even aware of it, and it had even less RAM. I'm guessing it, too, was at a lower resolution and probably had a lower polygon count?
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

I had a demo. It ran in a rubbish, muddy resolution with long loading times and everything set to low or off.
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

NeX wrote:

I had a demo. It ran in a rubbish, muddy resolution with long loading times and everything set to low or off.

Well, looks like the DS version is gonna disappoint you then! ;-)

In terms of RAM usage I'm not surprised that the game runs in low-memory configurations like on the N64 (not sure of the PSX). If the static model data and the program were in ROM then not a lot of memory would be required. If for the DS I could have all the world and model data in an instantly-available read-only format, I'd be sorted.
Since I can't distribute a 200MB ROM card, y'all are gonna need a 16+ MB RAM card!

EDIT: ooh...888 posts!
_________________
Big thanks to everyone who donated for Quake2

Couldn't you just do a repacking utility which "precalced" all the static model data?

Lord Graga wrote:

Couldn't you just do a repacking utility which "precalced" all the static model data?

seems quite a great job, and would surely prevent user to run mods...
by the way, gg for your 888 post simon

Soz that wasn't the point I was angling for ;-)
I meant that if the models were in an addressable place in memory there wouldn't be much use for extra RAM. The only reason it needs X MB of RAM on machines which have no ROM is cos the files need to be loaded from disk into the memory. If this was to be done for the DS I'd have to make a 200MB ROM but doesn't the GBA interface let you have only 32MB? If so, a ROM would be a no-go!

Quote:

by the way, gg for your 888 post simon

Yeah I need a new hobby... How many of those posts were in the Quake, yeah thread?!
_________________
Big thanks to everyone who donated for Quake2

From what I read, the PS version of Quake II was missing several level details and didn't have some of the larger maps at all. Seeing as how the system only had 2MB of RAM and 1MB of VRAM, I'm not surprised if they had to cut things way down. If anyone's curious, here's what Wikipedia says about the differences:
http://en.wikipedia.org/wiki/Quake_II#PlayStation
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

The PSX version also had Loading... points at almost every sliding door :)

It -did- have some neat changes like light coronas, and lens flares though :P

JLsoft wrote:

The PSX version also had Loading... points at almost every sliding door :)

Would you rather just have the door vibrate until the next room loads and then open once it's done? Or would that be a bit too Metroid?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I wonder if something like that would help for QuakeDS 2? One would think it would be faster reading from flash memory than reading from an optical disc.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

MechaBouncer wrote:

One would think it would be faster reading from flash memory than reading from an optical disc.

not sure if it's always the case, but flash will probably always be faster than a PSX optical drive...

Ok ok, I wanna share with you an *amazing* piece of code within the Q2 save system. I've spent the last three hours tracking this down and as a result, I'm pretty...disappointed.

So I just upgraded the game to C++ from C, fixed all the endless casting errors, float->int warnings etc. I run the game and the demos starting running straight away. Score. I go into the game...cue obscure message on the console...ok...and the game hangs. The exception handler won't kick in, the debugger doesn't trap it...nice.
After ages I realise that arguments to functions are getting corrupted but it actually turns out that functions are getting entered mid-function! Weird!

Basically, it seems that when the game loads a save file (either auto-saved, quick-saved or a regular save) all the function pointers associated with the entities in the game are dumped to disk. When the game is reloaded all the function pointers are restored and the game keeps on going.
However, what happens if the executable changes between saving/loading? None of the function pointers line up! One crashy game :-)

Seriously, wtf. This means that save files won't be compatible from PC->DS, DS->PC, one major DS version to another, or even from one build to the next! FFS.
_________________
Big thanks to everyone who donated for Quake2

HAHA!
Now you know how it feels!

It must be something unique to ID Software since Wolfenstein has this too except with data structures.
Maybe it's time for both projects to have their save code re-written :D

Aww man, can't believe they got you too! How on earth did they manage to diagnose problems in the game when save files couldn't be passed around?
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

However, what happens if the executable changes between saving/loading? None of the function pointers line up! One crashy game :-)

Even if the game didn't use function pointers, or the implicit function pointers in most C++ compilers' implementation of virtual methods, what would happen if the layout of a struct were to change between builds?

As for using save files to diagnose things, I'm sure they had the binaries and corresponding source of each daily testing build in some sort of revision control system.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Even if the game didn't use function pointers, or the implicit function pointers in most C++ compilers' implementation of virtual methods, what would happen if the layout of a struct were to change between builds?

Quake 1's save format is pretty much text - couldn't they have done something similar here? Plus 1997 was a bit early for XML :-)

Tbh I'm actually selling it kinda short - Q2 is made of several components, one of which is 'the game'. On the PC the game is loaded in separately as a dll to a fixed address, and accessed from there. It's this that all the function pointers point to, so as long as 'the game' doesn't change (they can change the renderer, the sound system - anything) then it's ok. But in many targets in the source package this DLL system isn't an option (and I've configured it that way for the DS, too) so you can't change anything without invalidating the save files.
Maybe I need to write some kind of DLL system for the DS (ugh)
...or I could just write a virtual function mapper of some sorts...
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Maybe I need to write some kind of DLL system for the DS (ugh)

Could you start with however MoonShell plug-ins and DSOrganize 2.7 to 3.0 plug-ins work?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Couldn't you just check if the function addresses have changed since the save and update them as necessary?

Here's some shots of the new 'disco lighting' mode :-)
http://www.dcemu.co.uk/vbulletin/showpost.php?p=2147992778&postcount=22
(linked to here cos they allow inline thumbs)

I still have to sort out the save system. I'm gonna fix it so I can have some kind of function mapper thing, it'll be a bit tedious to paste all the useable functions into a big table but it'll sort out game saves for ever more. It'll also allow me to run saves on the PC...
_________________
Big thanks to everyone who donated for Quake2

Looks great!
Do we get another video? :D

Will it be possible to run this with only a slot-2 card?
I have a Supercard CF and do not plan on getting another homebrew device.

Simon, supposedly you were planning on it running on Slot-2 devices, although you're currently having issues doing that. Am I correct?

Also, I'm assuming you're going to resize the HUD. I'm also assuming that you're going to keep it on the top screen, seeing that putting in on the top of the bottom screen would probably be pretty hard.

Those are awesome screens Simon. I don't know how you manage get Carmack's arcane code running on the humble DS. I've got a few questions.

1. I presume the initial release will run just the single player element of the original game and no multiplayer component.
2. I presume the minimum requirement with be a slot1+ram pack combo. Is there any noticeable speed difference between any of the currently available combo's r4+ez3-1>cyloc+ewin etc..? What is the kit of choice?
3. Later levels of Quake brought the framerate to its knees. Is this still the case with Quake2? I'd guess that the later bsps are exponentially bigger than any of the Quake 1 levels.
4. Quake2 had opengl support from the get go. Has this helped in the conversion and use of the DS 3D hardware?

Spike wrote:

1. I presume the initial release will run just the single player element of the original game and no multiplayer component.

Yep, that's right. I dunno if I'll ever bother with multiplayer though since it was a bit of a flop with QDS 1. The lag of the connection made it pretty unplayable... Plus you're only gonna get whupped by the machine that has better controls!

Quote:

2. I presume the minimum requirement with be a slot1+ram pack combo. Is there any noticeable speed difference between any of the currently available combo's r4+ez3-1>cyloc+ewin etc..? What is the kit of choice?

Nah it'll require just the one card. At the moment you need both a slot 1 and slot 2 because I've not yet written the support to allow both disk and RAM access to run from the same slot. It's annoyingly tricky to get right, but I'll do it when I get time. In terms to recommendations I'd got for a card that you can overclock, eg the EZ flash or M3. However I had a go on my Supercard (which is the slowest of them all) and the game ran fine... If you were buying one though, I'd get an EZ 3-in-1.

Quote:

3. Later levels of Quake brought the framerate to its knees. Is this still the case with Quake2? I'd guess that the later bsps are exponentially bigger than any of the Quake 1 levels.

This was due to the number of bad guys in the world, and this is why the more enemies you kill the faster I gets! I think I've fixed this in Q2, and I plan on rolling those changes back into Q1 too. There's now a minimal difference in speed in playing Q2 in easy or hard mode.
You're right though - the maps are nearly twice the size in Q2 vs Q1. The models are also more detailed.

Quote:

4. Quake2 had opengl support from the get go. Has this helped in the conversion and use of the DS 3D hardware?

No :-)
What has been a BIG help though is that the renderer is very similar to Q1 and the tranformations are almost the same, as are the data types. It was pretty easy to adapt the software renderer to use the hardware, since I'd already done all the work for Q1!
Also the sound and texture systems are exactly the same, so those months I spent working on the DS versions were not wasted. I literally dropped in the code and it all worked!
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

I dunno if I'll ever bother with multiplayer though since it was a bit of a flop with QDS 1.

:(

simonjhall wrote:

What has been a BIG help though is that the renderer is very similar to Q1 and the tranformations are almost the same, as are the data types. It was pretty easy to adapt the software renderer to use the hardware, since I'd already done all the work for Q1!
Also the sound and texture systems are exactly the same, so those months I spent working on the DS versions were not wasted. I literally dropped in the code and it all worked!

I guess that's why id Software calls both the Quake engine and the Quake II engine "id Tech 2". It might also be why people think GoldSrc (original Half-Life engine) is based on Q2, when it's actually a heavily customized Q1 engine.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

simonjhall wrote:

Spike wrote:

1. I presume the initial release will run just the single player element of the original game and no multiplayer component.

Yep, that's right. I dunno if I'll ever bother with multiplayer though since it was a bit of a flop with QDS 1. The lag of the connection made it pretty unplayable... Plus you're only gonna get whupped by the machine that has better controls!

I still play the QuakeDS multiplayer so its not been a flop with me. Admittedly I play 1v1 against a bot on small-ish DM maps but it plays a treat. The vanilla QuakeDS build is super speedy. So all that hard work getting the net code up and running wasn't in vain from my perspective.

simonjhall wrote:

Spike wrote:

2. I presume the minimum requirement with be a slot1+ram pack combo. Is there any noticeable speed difference between any of the currently available combo's r4+ez3-1>cyloc+ewin etc..? What is the kit of choice?

Nah it'll require just the one card. At the moment you need both a slot 1 and slot 2 because I've not yet written the support to allow both disk and RAM access to run from the same slot. It's annoyingly tricky to get right, but I'll do it when I get time. In terms to recommendations I'd got for a card that you can overclock, eg the EZ flash or M3. However I had a go on my Supercard (which is the slowest of them all) and the game ran fine... If you were buying one though, I'd get an EZ 3-in-1.

I have already have a R4/EZ3-1 combo so that's cool and the gang.

simonjhall wrote:

Spike wrote:

3. Later levels of Quake brought the framerate to its knees. Is this still the case with Quake2? I'd guess that the later bsps are exponentially bigger than any of the Quake 1 levels.

This was due to the number of bad guys in the world, and this is why the more enemies you kill the faster I gets! I think I've fixed this in Q2, and I plan on rolling those changes back into Q1 too. There's now a minimal difference in speed in playing Q2 in easy or hard mode.
You're right though - the maps are nearly twice the size in Q2 vs Q1. The models are also more detailed.

Sweet!

simonjhall wrote:

Spike wrote:

4. Quake2 had opengl support from the get go. Has this helped in the conversion and use of the DS 3D hardware?

No :-)
What has been a BIG help though is that the renderer is very similar to Q1 and the tranformations are almost the same, as are the data types. It was pretty easy to adapt the software renderer to use the hardware, since I'd already done all the work for Q1!
Also the sound and texture systems are exactly the same, so those months I spent working on the DS versions were not wasted. I literally dropped in the code and it all worked!

All sounds very promising. I can't wait to have a crack at the single player again.

Thanks for the detailed info. I just like to take this opportunity to wish you and all the other uber DS homebrew coders who frequent this forum a Merry Christmas.

Cheers.

As an M3 Lite owner and a mainly Quake II multiplayer user, the lack of support for both of those would make me cry... D:

The game now runs fine on just one flash card, in case anyone's wondering. So a lone M3 lite should be fine... (that's a full M3, for the non phat DS right?)
Also the multiplayer maps do play exceptionally well so I may have to stick some kind of MP in. However the lag was totally annoying on QDS 1 and I don't think it'll be gone if I were to do it again...
_________________
Big thanks to everyone who donated for Quake2

I remember when quake 2 first came out, one of the things I thought BEST about it was the improvement made on the multi player aspects of the engine. playing original quake was laggy as hell, before quakeworld, but quake 2 had much better ping times strait out of the box.

perhaps it's safe to say the same might be true of the DS's iteration of the game? I say try for it, if it's not more hassle than it's worth. might prove to be a winner.
_________________
-01011101001010101010 (frank)

I can't seem to get good ping times from the homebrew wifi library, and this really impacts on the game. Yeah I know it's got client-side prediction and such but it'd still be nice to have low pings :-)
Plus there seems to be a bandwidth issue - however hard I try, I can only get a very low transfer rate in and out of the DS and this causes even more problems!

We'll see :-)

But on the plus side, the rest of the game is pretty much there now.
What's left to do:
- sprites aren't rendered
- lasers aren't rendered
- view weapon clips the gui
- the key config menu doesn't fit on the screen
- game saves don't work correctly (it's a directory listing issue, not a file saving issue)
- osk needs to go in
- needs some testing on the different flash cards
- only two levels don't load, and they're not due to being short on RAM

A 16 meg card is the minimum. I nearly got it into 8MB for the Opera RAM pack but it would have taken too much time...
_________________
Big thanks to everyone who donated for Quake2

About the low ping times, could you be a little more specific? Are we talking 100-200ms or more like 600-1000ms?

And yes, the M3 Perfect Lite is designed to not stick out on DS lites, even though I have a DS phat XD (it comes with a GBA-sized shell too)

So, uh... about that testing part... I know asking to be a tester is typically frowned upon, but I do belive I am a dying breed :P

Own a near-launch silver DS phat (originally v1 firmware)
Also have a refurbished Blue DS phat (had v5 firmware, but the multiple brightness hack doesn't work, so it was probably originally firmware v4)
M3 Perfect Lite - that's used on a DS phat

(I have 2 DSes because the first one has a dead L button now >_> The credit card company extended our warrenty and I didn't even have to send the old one back XD)

man, i have it, that whenever i play a q2 based game on XP (q2, kingpin - sof works fine, though) i get an "function pointers moved" error message and can't load my savegames (especially crappy when you're near a level's exit and the player dies and your quicksave doesn't work anymore!).
that was damn annoying. anyone else got the probolem?
sorry for being slight offtopic (well, more kinda out of focus, isn't it?).

greets to simon - very good work so far!

That'll mean that the game dll you're running with is not the same one used to make the save. If you just start the game, make a save, then reload it do you get the problem then?

Since I doubt you're recompiling the dlls yourself try reinstalling the game dll (it'll be inside the game directory and named something like gamex86.dll) and having a look around to see if the game has loaded another dll instead (ie there's one on the path that shouldn't be there).

This dll stuff is the reason that I'm not supporting mods and total conversions on the DS version :-(
Windows x86 DLLs != teh ARM
_________________
Big thanks to everyone who donated for Quake2

well, it's been a while, but i've had the game installed and it ran, though with the error. updated it, but it was the same. as i said, kingpin is all the same. i remember having a computer with XP-SP1 installed and i'm tempted to beleive that problem didn't exist then. but who knows?
actually i was also compiling my own mods for q2 back then, but that had no influence on the behaviour (i allways had the original .dll at hand). sort of sucks i can't complete kingbin and the q2 mp! was nearly done with the first one (player couldn't die too often). thw: it looked pretty random to me, because most of the time everything worked and then POP! in your face, won't load.

btw: half life is based on q1, yes, but it used about 50 lines of q2's multiplayer code... guess why? ;^p

I think in windows that dlls have preferred base addresses, but this is not guaranteed. so, if another dll that is attached to the process loads at the same address I think it will relocate automatically. based on simon's description of the save code this could be a potential issue. a lot of programs install dlls into the AppInit_DDLs registry key. this will cause them to load into all processes under windows.

Just a quick funny before I finally go to bed.
So I've been working for a while now to multithread Q2 by sticking bits of the renderer on the ARM7 whilst I run the game on the ARM9.
Well I've sorted out the memory arrangements sufficiently to allow me to do what I want to do now, and to in particular time the code when running on the second core.

BSP traversal on a complicated scene:
- ARM9, from slow RAM, cached, 15.5ms / frame
- ARM9, from main RAM, cached, 14.5ms / frame
- ARM7, from slow RAM, uncached, 20.5ms / frame (THUMB)
- ARM7, from main RAM, uncached, 19.5ms / frame (THUMB)
- ARM7, from main RAM, uncached, 14.2ms / frame (ARM)

Ha ha! Anyone want to draw any conclusions?
Both processors have the code running from either itcm or wram, with the ARM9 in ARM mode. The recursion stuff has been flattened into a manually-done stack that lives in either dtcm (ARM9) or WRAM (ARM7). There's no floating-point code in use - it's all in integer. Compiled with -Os. The slot-2 memory has its timings set as high as they will go.
_________________
Big thanks to everyone who donated for Quake2

Cached slow RAM? Shouldn't the cache's speed be constant despite of the memory it's caching?

Also, how did you get it to work? :D
_________________
http://licklick.wordpress.com

Wait, the ARM7 is faster?
_________________

dualscreenman wrote:

What about Gaim DS? Gaim pretty much has support for all IM programs.

tepples wrote:

"Goshdammit, the DS is not a Gaim-boy! It's a third pillar!"

That makes sense:

Quote:

The two Processors
Most game code is usually executed on the ARM9 processor (in fact, Nintendo reportedly doesn't allow developers use the ARM7 processor, except by predefined API functions, anyways, even with the most likely inefficient API code, most of the ARM7's 33MHz horsepower is left unused).
The ARM9's 66MHz "horsepower" is a different tale - it seems Nintendo thought that a 33MHz processor would be too "slow" for 3D games, and so they (tried to) badge an additional CPU to the original GBA hardware.
However, the real 66MHz can be used only with cache and tcm, all other memory and I/O accesses are delayed to the 33MHz bus clock, that'd be still quite fast, but, there seems to be a hardware glitch that adds 3 waitcycles to all nonsequential accesses at the NDS9 side, which effectively drops its bus clock to about 8MHz, making it ways slower than the 33MHz NDS7 processor, it's even slower than the original 16MHz GBA processor.
Altogether, with the bugged 66MHz, and the unused 33MHz, Nintendo could have reached almost the same power when staying with the GBA's 16MHz processor :-)
Although, when properly using cache/tcm, then the 66MHz processor <can> be very fast, still, the NDS should have worked as well with a single processor, though using only an ARM9 might cause a lot of compatibilty problems with GBA games, so there's at least one reason for keeping the ARM7 included.

While going trough a BSP-tree, the arm9 can only read it at 33Mhz, same speed as the arm7. So I guess that here the limiting factor is the data read access, since the arm7 achieve the same speed as the arm9.

The strange thing is that we could have thought that the arm9 cache would speed up the things a little... Maybe you should try to cache the BSP tree (or parts of it) into the DTCM?

Lick wrote:

Cached slow RAM? Shouldn't the cache's speed be constant despite of the memory it's caching?

There's cache misses too, and they take longer to the slower memory. I don't think the cache does one bit for this algorithm!

Quote:

Also, how did you get it to work? :D

Which bit? :-)

Quote:

Wait, the ARM7 is faster?

The ARM9 is doing slightly more work that I'm making it out, but yeah they're basically the same speed running this algorithm. I'm gonna try timing the other algorithms too, to see how they compare. Bit of a shocker eh - I wasn't expecting this!

Quote:

The strange thing is that we could have thought that the arm9 cache would speed up the things a little... Maybe you should try to cache the BSP tree (or parts of it) into the DTCM?

Yeah, the cache seems to do FA. I don't have the tools to measure which lines are the most expensive, so I can't see what I need to improve. But I'd imagine that I'm getting gallons of cache misses since the algorithm darts all over memory. Plus isn't the cache like two-way? I touch quite a few different parts of memory with this code.
Anyway I'd like to try and cache it but I wouldn't know where to start! I've tried those prefetch instructions but I don't think they actually work. Btw there's far too much data to stick the whole lot in one fast piece of memory.
_________________
Big thanks to everyone who donated for Quake2

BSP-nodes aren't reused until next frame, so caching them isn't going to help much. If a BSP-node is smaller than a cache-line, you might be suffering by the fact that you always need to load a whole cache-line at the time. Have you tried disabling the cache on the ARM9?

The game surprisingly runs very well with the data cache disabled! In fact I was actually in doubt that it's turned on! Synthetic tests do show that it's on, though.
And yeah I shrunk the bsp nodes so that more than one can fit within a cache line - but yeah I guess there's not a lot of locality-ness within the structure in memory so the next node (ie the second one pulled into the cache) is likely to not get used.
__builtin_prefetch generates the right instructions (when coompiled with the right compiler type), but it doesn't actually seem to have any effect.
I'll post the code later so people can pick it apart.
_________________
Big thanks to everyone who donated for Quake2

Simonjhall: I'm very surprised to see the ARM 7 work so well for the BSP nodes.

Overall, how's the project coming along now? What would you say the average frame rate is? How's the texture pop-in? Does it run faster on an M3 vs a supercard? How's the sound engine doing and will there be any music?

All those questions are curely out of curiosity. I never even expected to see this project to get this far, just due to the sheer difficulty of it for one person, without working with a Nintendo SDK.

Wouldn't it be amazing if you could outdo the N64/PSX ports of the game on the DS? I'd think so.

Doom5 wrote:

Wouldn't it be amazing if you could outdo the N64/PSX ports of the game on the DS? I'd think so.

the only real benefit whould be to try to squeeze quake 2 to let it run on a DS without the EXRAM or with only the 8Mo ram... the regular pak run quite good on the DS, of course smaller pak (like the shareware one) are a little bit faster but the regular .pak run quite fast enough, and Simon is really doing a great and impressive work to manage to run quake2 so well on a DS.

ho and I am also not sure that the games assets of the psx/N64 are regular .pak files, and the source for these version are, I do not think, released...

Doom5 wrote:

Simonjhall: I'm very surprised to see the ARM 7 work so well for the BSP nodes.

Pretty weird, isn't it?! Although I'm still disappointed with the speed. I spent a lot of time on the bsp rendering on QDS 1 but not as much time as I've spent on the Q2 renderer and yet it's still half the speed! I'm guessing the maps are much more complicated, or something...

Quote:

Overall, how's the project coming along now?

It's mainly done. If I were to compare it with the first game, I reckon it's at the same state that pre-release two was. It's mainly the optimisation and bug fixing that I'm dealing with at the moment. Only two levels aren't loading, and the save system *still* hasn't been written!

Quote:

What would you say the average frame rate is?

Depends, plus I've still got to do a lot of tuning. Demos play at about 20-40fps, but in game it's still pretty crap and I'm taking some nasty measures to lift it up on some levels. The client-side prediction is wasting a lot more than I'd expect...

Quote:

How's the texture pop-in?

Similar to the first game - you'll rarely see wall textures load, but monsters are handled differently in this game. Btw textures load much faster in this game. In the first game each monster only had one texture (apart from the few which were animated). In this game monsters can also have a 'damaged' texture, so the first time you shoot someone they'll flash white whilst the texture's pulled in! I'm trying to add a solution for this that won't break PC<->DS multiplayer.

Quote:

Does it run faster on an M3 vs a supercard?

Yes. Load times are also much better when you don't use the Supercard RAM. One interesting thing is that if you use just an M3 (ie no slot-1 card for data) you can't overclock the M3 as much... Use it conjunction with the slot-1 card and it'll clock faster!
The card I'd really recommend is the EZ-flash, since the memory is the fastest. I use a 3-in-1.

Quote:

How's the sound engine doing and will there be any music?

Sound system's in, yet Elwing can crash it...somehow! I haven't considered music at all yet. If I do decide to MT the renderer there definately won't be music. Video/cutscene playback will probably go in, but it's not in yet.

Quote:

...just due to the sheer difficulty of it for one person, without working with a Nintendo SDK.

If I had a profiler that could give per-line stats then I could do a much better job. Function instrumentation is much too granular! A better compiler would be nice too! (kusma?!)

Quote:

Wouldn't it be amazing if you could outdo the N64/PSX ports of the game on the DS? I'd think so.

I doubt the data would be compatible. I bet the levels are just RAM dumps of what the read-only parts of levels look like when they're loaded :-)

Wow - that was one big post!
_________________
Big thanks to everyone who donated for Quake2

simon - are the bsp times just for one pass of the renderer? if it takes that long then the hull checking code for movement must be crippling.

Wow... I didn't knew that the DS' Ram was used so inefficiently and the Arm 7 is nearly not fully useable. Sigh, I wished Nintendo could find a way to get this working better and nearly use the full horsepower :( .
_________________
Starcraft DS ?

Looks awesome Simon. I was wondering something though, couldn't you use all these new optimizations on Quake 1 DS? I am asking this mainly because the game suffers a severe slow down in the Crypt of Decay level, which prevents me from finishing the game. I'm using a M3 Lite and it was running the game fine up until now. In any case, keep up the good work, you're achieving amazing things that are very positive for the NDS homebrew scene!

elhobbs wrote:

simon - are the bsp times just for one pass of the renderer? if it takes that long then the hull checking code for movement must be crippling.

Yeah, that's right - just one frame of rendering. The hull checking is equally as slow, yet is run many more times per frame. The algorithm is a bit different, and still uses a load of fp math. It's called many dozens of times per frame and adds up to roughly the same amount of time as one pass of the bsp. It's the #1 function that I'm trying to sort out.
Don't ask me about the speed difference - they're not my algorithms!

@alex: yes I will roll back the stuff I've learnt into the other game. With the problem you're referring to, this is a bug I found after doing the third release. I don't think it's in r2 so try loading your saves in that to get passed that bit. It'll get fixed, at some point :-)

EDIT: turning off the slot-2 data caching improves the average framerate by 10% - FFS, I wish I knew what was going on with this chip!
EDIT2: I think it's also time that I wrote a combined ARM emulator/instruction-level profiler to time code in
_________________
Big thanks to everyone who donated for Quake2

Another quick one - what do people think about the FMV cut-scenes?
I've got them going and there are lots minor issues with them, but there are also some definate problems with the frame rate (surprise surprise).
Did anyone actually even notice the cuts when playing Q2 before? Should I just disable them?

Adding proper support for them would probably take 2-3 weeks extra time...
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Another quick one - what do people think about the FMV cut-scenes?
I've got them going and there are lots minor issues with them, but there are also some definate problems with the frame rate (surprise surprise).
Did anyone actually even notice the cuts when playing Q2 before? Should I just disable them?

Adding proper support for them would probably take 2-3 weeks extra time...

Cutscenes aren't a big deal, but maybe you could just have a config option to enable/disable them?

simonjhall wrote:

Another quick one - what do people think about the FMV cut-scenes? Adding proper support for them would probably take 2-3 weeks extra time...

I never bothered with them, as they didn't add much to the game. My vote: save 2-3 weeks.

that would be nice to have cutscene, but:
1- the quake2 cutscene are not great and i think that everything in them is resumed in the mission tab...
2- that would require too much time coding.
3- that will take increased size required on the flash-card, is it worth it? probably no, quake 2 is not the only app on my miniSD card...

now it's up to you, but in any case i guess we could wait later for them...

they are not worth week of coding

gbadev.org forum archive

DS development > Yeah, Quake2

#123278 - simonjhall - Mon Mar 26, 2007 10:55 pm

#123279 - tepples - Mon Mar 26, 2007 11:11 pm

#123288 - Miika - Tue Mar 27, 2007 1:11 am

#123289 - Dood77 - Tue Mar 27, 2007 1:21 am

#123293 - Ant6n - Tue Mar 27, 2007 1:36 am

#123301 - Mr. Picklesworth - Tue Mar 27, 2007 3:08 am

#123306 - MelGibson - Tue Mar 27, 2007 5:12 am

#123317 - HyperHacker - Tue Mar 27, 2007 7:37 am

#123325 - MelGibson - Tue Mar 27, 2007 8:21 am

#123326 - OOPMan - Tue Mar 27, 2007 8:24 am

#123332 - Lord Raptor - Tue Mar 27, 2007 9:35 am

#123333 - simonjhall - Tue Mar 27, 2007 9:44 am

#123334 - MelGibson - Tue Mar 27, 2007 9:52 am

#123344 - simonjhall - Tue Mar 27, 2007 2:25 pm

#123346 - MelGibson - Tue Mar 27, 2007 2:57 pm

#123347 - daninski - Tue Mar 27, 2007 3:22 pm

#123403 - silent_code - Tue Mar 27, 2007 10:35 pm

#123419 - Dood77 - Wed Mar 28, 2007 12:33 am

#123426 - Nintendo Maniac 64 - Wed Mar 28, 2007 2:04 am

#123430 - tepples - Wed Mar 28, 2007 2:37 am

#123437 - Nintendo Maniac 64 - Wed Mar 28, 2007 5:21 am

#123454 - xtoc - Wed Mar 28, 2007 9:03 am

#123460 - PeterM - Wed Mar 28, 2007 9:58 am

#123468 - simonjhall - Wed Mar 28, 2007 11:06 am

#123521 - Payk - Wed Mar 28, 2007 8:35 pm

#123551 - MelGibson - Thu Mar 29, 2007 12:50 am

#123575 - Miika - Thu Mar 29, 2007 6:12 am

#123590 - HyperHacker - Thu Mar 29, 2007 10:14 am

#123593 - Miika - Thu Mar 29, 2007 12:58 pm

#123594 - simonjhall - Thu Mar 29, 2007 1:31 pm

#123652 - Nintendo Maniac 64 - Thu Mar 29, 2007 11:10 pm

#123699 - Miika - Fri Mar 30, 2007 12:21 pm

#123705 - tepples - Fri Mar 30, 2007 1:49 pm

#123710 - MelGibson - Fri Mar 30, 2007 2:43 pm

#123740 - tepples - Fri Mar 30, 2007 7:48 pm

#123759 - Ravey - Fri Mar 30, 2007 9:57 pm

#123762 - Ant6n - Fri Mar 30, 2007 10:14 pm

#123764 - simonjhall - Fri Mar 30, 2007 10:37 pm

#123773 - Ant6n - Sat Mar 31, 2007 12:08 am

#123778 - PeterM - Sat Mar 31, 2007 12:48 am

#123782 - Miika - Sat Mar 31, 2007 1:42 am

#123783 - chuckstudios - Sat Mar 31, 2007 1:57 am

#123786 - Miika - Sat Mar 31, 2007 2:51 am

#123973 - theli - Mon Apr 02, 2007 7:04 am

#124012 - tepples - Mon Apr 02, 2007 1:47 pm

#124013 - dualscreenman - Mon Apr 02, 2007 1:56 pm

#124026 - Miika - Mon Apr 02, 2007 4:30 pm

#124030 - MelGibson - Mon Apr 02, 2007 4:35 pm

#124092 - yackom - Tue Apr 03, 2007 2:32 am

#124137 - simonjhall - Tue Apr 03, 2007 1:59 pm

#124138 - Sunray - Tue Apr 03, 2007 2:18 pm

#124139 - PeterM - Tue Apr 03, 2007 2:24 pm

#124143 - tepples - Tue Apr 03, 2007 3:17 pm

#124144 - PeterM - Tue Apr 03, 2007 3:34 pm

#124195 - kekit - Tue Apr 03, 2007 11:59 pm

#124198 - masterchief - Wed Apr 04, 2007 1:00 am

#124278 - bear - Wed Apr 04, 2007 8:28 pm

#126436 - Tockit - Mon Apr 23, 2007 6:14 am

#126451 - simonjhall - Mon Apr 23, 2007 9:33 am

#126452 - Lick - Mon Apr 23, 2007 9:47 am

#126456 - kusma - Mon Apr 23, 2007 10:00 am

#126457 - simonjhall - Mon Apr 23, 2007 10:25 am

#126458 - Lick - Mon Apr 23, 2007 10:43 am

#126462 - simonjhall - Mon Apr 23, 2007 12:03 pm

#126476 - Dudu.exe - Mon Apr 23, 2007 4:16 pm

#126484 - simonjhall - Mon Apr 23, 2007 6:35 pm

#126514 - Masterofdarkness - Tue Apr 24, 2007 12:17 am

#126515 - tepples - Tue Apr 24, 2007 12:45 am

#126516 - Masterofdarkness - Tue Apr 24, 2007 12:54 am

#126523 - dantheman - Tue Apr 24, 2007 1:32 am

#126526 - Ant6n - Tue Apr 24, 2007 1:48 am

#126527 - Masterofdarkness - Tue Apr 24, 2007 1:57 am

#126531 - Dood77 - Tue Apr 24, 2007 4:28 am

#126534 - tepples - Tue Apr 24, 2007 4:41 am

#126542 - simonjhall - Tue Apr 24, 2007 9:29 am

#126552 - Masterofdarkness - Tue Apr 24, 2007 12:13 pm

#126699 - darkNiGHTS - Thu Apr 26, 2007 1:35 am

#145912 - simonjhall - Sun Nov 25, 2007 3:23 pm