gbadev.org forum archive

Back from the Debugger Wars and have been looking for something to do for a laugh...but I may have bitten off more than I can chew!

Not that I wanna show off, but check:
[Images not permitted - Click here to view it]
here's me running around a deathmatch level on my DS.

Note: I just did this for fun one weekend, and John (the guy who's doing the first Quake port) sounds like he's doing much better at this Quake lark than me and definately has the better version in the works - so wait for that!

But for those who are interested, I've got the software renderer running Quake. I've not yet decided whether I'm gonna asm-up the renderer or simply try doing GLQuake->DS.

I have no idea how I would'a done it without that debugger of mine :-)

---

As RAM usage is beyond tight with this game I've written some memory-mapped file thing - I may open this up if there's enough interest... Basically rather than freading in a file (which will take memory) then picking out the bytes you need you just 'load' a file into part of the address space then you can access it like regular memory. And yeah, you could also do some kind of virtual memory thing with it if you wanted to.

Nice!
Especially since it looks like the other quake project is dead.

How is the framerate anyway? Dropping -mthumb should give a nice speedup if you haven't already done that.

simonjhall wrote:

I've not yet decided whether I'm gonna asm-up the renderer or simply try doing GLQuake->DS.

The latter might be a good idea, if only because that's how a commercial port would more than likely do it.

Quote:

As RAM usage is beyond tight with this game I've written some memory-mapped file thing - I may open this up if there's enough interest... Basically rather than freading in a file (which will take memory) then picking out the bytes you need you just 'load' a file into part of the address space then you can access it like regular memory. And yeah, you could also do some kind of virtual memory thing with it if you wanted to.

How much performance penalty does this take? If not much, it could be useful in porting SnezziDS (which assumes that the entire Super NES ROM is mmapped into GBA ROM space) to the GBA Movie Player, MAX Media Dock, and SLOT-1 cards.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Wait a sec... isn't memory-mapping whole files exactly the opposite of what you'd want to do when facing a memory bottleneck?

Or do you mean you're using processor exceptions to forward out-of-range memory accesses to the ROM? If so, isn't that painfully slow, like 50+ cycles per access?

It looks like this Quake port is better from the get-go than the other one, which didn't even have texture rendering, last time I checked...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Ok, gonna try and answer all the questions in one go:

Quote:

It looks like this Quake port is better from the get-go than the other one, which didn't even have texture rendering, last time I checked...

I think they've got texture mapping going on, but as they use hardware rendering all the textures need to fit inside the texture memory (512k - is that true?) As a result things need to be resized on the fly or done offline.

Also I hear that there's a poly limit on the DS hardware. Can anyone confirm this?

Quote:

Especially since it looks like the other quake project is dead.

I've been assured that it's not, he's just not updated the blog. I think he has been busy with other things though.

Quote:

How is the framerate anyway? Dropping -mthumb should give a nice speedup if you haven't already done that.

Again, I've done zero work in terms of making it fast as speed isn't my concern yet so I'm gonna hold off on talking about framerates! (it is real-time though) One thing which I think may be an issue is that Quake requires an FPU - something the DS doesn't have. I think I'm gonna have to write a profiler...

Actually, I've tried profiling it running on other machines but I'd like to compile with --soft-float to get useful info but I always get linker errors.

Oh and I don't think I ever finished thumb support in the debugger...or did I?

And regarding memory mapped files, the biggest problem with Quake is obviously the memory usage. For example, when loading the necropolis level it'll allocate 1.5 megs, fread the file in then go though each chunk of the model (vertices, textures, nodes, etc) and allocate memory for them. So by the end of loading the model you've allocated 3 megs of RAM - 3 megs I don't have. It'll then free the original 1.5 megs. I can either rewrite the code to fread tiny kilobyte chunks or I can just be lazy and memory map files. I may end up just rewriting the code to get the speed...

I am having this weird-ass bug though - there's no friction with the floor! I ported it to another platform first just to see potential issues and I had no friction problem...

Hmmmm, yeah, the DS does have about 600kb of VRAM, but it's organised in a rather different fashion from your average chunk of memory...

Also, yeah, the DS has a poly-limit of about 4000 per scene (Although the HW is technically supposed to be capable of more...)

The memory-mapped files stuff sounds interesting. Does anyone know whether this kind of thing is more difficult to use than the extra memory on the SC and M3, or less difficult? Can anyone guess how it compares speed-wise?

That friction bug sounds weird. Hmmmmm, I wonder, might it not have something to do with ther maths side of things. The DS doesn't have an FPU and if the friction code uses FPU math and hasn't been updated/changed to use fixed-point math instead it might have issues...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Right, for now I'm gonna try and pursue the software-rendered route. I'm a little wary of using the hardware renderer as I reckon it's gonna be such an arse to get running! It will be faster in the long run though.

So in order to improve the performance of the sw renderer I've been scouting round for a fp-less version of Quake and came across PocketQuake. I've since been merging as many of the changes as I can from their version into DSQuake, but I bet money that it won't work first time :-)

Oh and I've fixed the friction bug and it's now so much more playable...
It's yet another thing I've found in the source which isn't cross-compiler friendy!

EDIT: I've just spent several hours merging in the fixed-point code...and surprise surprise it doesn't work. The PocketQuake source code is incomplete! Several major functions are called but aren't supplied in the zip! What a waste of time...

Ok, for those who want the shimmy on memory-mapped files I've just got the complicated part of the system working - putting the actual file stuff in is totally easy from here on.

BUT. Big ol' but :-) I thought I'd better check out the performance of the address-trapping system before finishing it off, and I just had to let out a groan... Inital tests said that I'd be able to get a peak of about 30k/s which is just terrible when you'd like to load a file that's larger than a megabyte!

To get this thing to work I integrated it with the debugger, and looking back over the core exception-handling functions I noticed that I'm flushing the data cache twice and the instruction cache twice! If I remove any of these calls both the debugger and mmap stuff go wonky really quickly. If however I remove all the cache calls and put a single cache flush call into my regular user-space function straight after the fake read it's all fine! And the performance increases to 60k/s!

So now I'm seeing if I can flush selected cache lines in order to make it work and get it running ten times as fast. There's still some hope of mmapped files being worthwhile.

Just for info: does anyone know what the average (read) transfer rate of a GBAMP (CF) is? How about main RAM too? (I'm too lazy to do a test)

simonjhall wrote:

Just for info: does anyone know what the average (read) transfer rate of a GBAMP (CF) is?

This depends heavily on the make and model of CF card. See my CF Speed Tester.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Ta man, I'll check that in a bit as I'll have to recompile it as an nds (but really should go to sleep)...

mmap again: I've got it up to 180k/s (though I'm pretty sure I got it to 220k/s at one point) so all is not lost. Given the massive overhead of the exception stuff (it's gotta be AT LEAST 1000 clocks) adding the file stuff ain't gonna cripple it. This also means that if you have one of those cards with the extra RAM you could totally map it in through this interface.
You'd just have to treat it like slow RAM.

OOPMan wrote:

Also, yeah, the DS has a poly-limit of about 4000 per scene (Although the HW is technically supposed to be capable of more...)

there's only memory for 2k triangles, though you can render more. using strips won't give you more triangles, because the hw isn't limited by vertex count, but triangle count (kinda both, but as i said, saving vertices by using strips won't increase triangle memory ;p ).

all you need to be careful about is your vertex count: don't use up all 6k vertices as the hw needs some free vertex memory for clipping (generates new vertices).

i think you can render up to 4k tris at 30 Hz, but i have to yet try that myself. the hw is sure capable of more and looking at those memory limitations, it's a bit sad. :C

happy coding!

For those who're wondering, yes I'm still porting Quake to the DS but I've been busy at work etc...plus I've been having a go with porting Quake 2 too :-)

Anyway couldn't be bothered to open a new thread: how do I get the default libnds text console to span both the screens? I'm not doing anything graphical at this point, so I don't care about trashing what's on the second screen. At the moment I'm just using consoleDemoInit()...

Thanks guys!

great , quake II i still my nr1 game if it go's about fps multiplay

So...nobody knows how to (easily) extend the libnds console over two screens? Touche.

Anyway, I've given up with the memory-mapped files. It'll work in most circumstances but I'm pretty sure something is trashing my stack pointer once every blue moon. This occurs after the last valid instruction is run, yet before the very first instruction of my exception handler so it has to happen in some kind of bios-y code. What I really want is some kind of hardware breakpoint system where the processor itself will catch the change of $sp... (I need an emulator!)

So I've decided to bite the bullet and rewrite the Quake level-loading code instead of endlessly fixing mmapping. I'm not half as enthusiastic about this game as I used to be :-(

On the bright side, it'll be a lot faster when you're done. :)

simonjhall wrote:

I'm not half as enthusiastic about this game as I used to be :-(

I had that problem when I was working on my first port of wolf3d, after a while adding onto hack after hack just wasn't fun anymore.
All I did was start again and the interest is back again.

Woo to you sir. Good stuff you've got going on there. Quake/Q2 would be the pinnacle of all DS ports, I feel. Hope this all works out well.

Yeah, I'm having problems with Quake 2 at the moment as I've got the demo playing, but I can't actually get into the game... The level-change message from the client to the server just doesn't seem to get through.

I'm also going on holiday tomorrow for a few weeks so don't expect me to reply if you wanna know more!

Any plans to release the latest source for people to hack around with?

Lazy1 wrote:

Any plans to release the latest source for people to hack around with?

If/when I choose to release Quake for the DS I'll package the source as that's a required part of the license. But as for giving it out this eve...oooh...err...nah! I've not yet packed for my hols, so there's no time! Sorry!

Actually, does anyone here have any experience with the Quake engine? I've been playing Quake on the tube in the morning but upgrading the networking has somehow corrupted my save file! And I was nearing the end of the game! No fair!

Did you play through on the DS version, or PSP version?

It's nice if you can actually play that far on the DS version :-)

Anyway, good luck with the project...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

simonjhall wrote:

Lazy1 wrote:

Any plans to release the latest source for people to hack around with?

If/when I choose to release Quake for the DS I'll package the source as that's a required part of the license. But as for giving it out this eve...oooh...err...nah! I've not yet packed for my hols, so there's no time! Sorry!

Actually, does anyone here have any experience with the Quake engine? I've been playing Quake on the tube in the morning but upgrading the networking has somehow corrupted my save file! And I was nearing the end of the game! No fair!

noooooo

Devil_Spawn wrote:

noooooo

:-)
I'll let you stew on that for a while :-p
Vegas here I come!

Vegas? You poor poor man...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

OOPMan wrote:

Vegas? You poor poor man...

Well...if not poor yet, he will be :P

off topic: just got back from my trip and the time spent in Las Vegas was awesome! Having one of the tires on our coach blow out in the middle of the night in the middle of the Mojave Desert wasn't too much fun though... Also a bit hairy when another tire decided to blow on the way to LAX!

Time to get back to work with Quake...

Woot :-)

Go get 'em :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Guys, just for a laugh (and I'm bored of the endless Quake 2 slog) I'm just gonna put a little vid up of Quake 1 running on my DS.

I'm too lazy to edit the Quake config file, so this is it running UNLIT AND UNTEXTURED.

http://myweb.tiscali.co.uk/simonhall/quake.avi
It's about two megabytes in size.

I'm still messing around with the model loading and networking, so I've still not bothered with changing it to fixed-point fp (so it's using software-emualted fp) nor attempted to use the DS' 3D hardware to make it run faster.

Back to Q2... (why couldn't they have put more RAM in the DS?!)

Thanks for the video. I'm on really crappy dial-up so it'll take a while before I can see it. :-)

Edit:

I saw the video, very neat!

Does the game load textures and just not render with them, or not load them at all? I ask because when I was porting Quake to the PSP I didn't have to fight against memory limits at all, but I could see that getting the memory usage down below 4MB may be difficult.

Did you employ any special tricks to get the memory footprint down?

BTW good luck with Q2 -- AFAIK nobody's been able to get that running decently on PSP yet so it'll be very very impressive if you get it doing on the DS (and I may just have to pinch the code!)
_________________
http://aaiiee.wordpress.com/

Last edited by PeterM on Sat Nov 25, 2006 7:50 pm; edited 1 time in total

simonjhall wrote:

Back to Q2... (why couldn't they have put more RAM in the DS?!)

Yeah, I thought the N64 expansion pak would have shown them that 4MB is not enough...
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

Yeah, I thought the N64 expansion pak would have shown them that 4MB is not enough...

Oh... <starts to shake a bit>

Doing a quick look online (and I'm talking quick!) seems to imply that you don't require the expansion to play. Plus didn't the N64 have 4 megs of RAM, like the DS? It would be so much easier if I could run my code out of cartridge space and allow the game to use the full 4 megs for data.
Is this possible?

Quote:

Does the game load textures and just not render with them, or not load them at all?

No, they're being loaded just not drawn. Just at the moment for some levels there's not enough RAM so I just normally roll without texture maps. The stuff I'm writing at the moment should allow it to run properly though.

Oh and I've seen Quake on the PSP - it's good! Did you use the software renderer? Shame there's so much lag on the LCD! The DS doesn't seem to suffer from that problem. Just a crappy framerate!

Yes, N64 had 4MB but was boosted to 8MB by the Expansion Pak. Some games just added extra features or higher resolutions, but others required it.
_________________
I'm a PSP hacker now, but I still <3 DS.

simonjhall wrote:

Doing a quick look online (and I'm talking quick!) seems to imply that you don't require the expansion to play.

Some games (Donkey Kong 64; LoZ: Majora's Mask) absolutely required the expansion, and others (Perfect Dark) presented only a tutorial mode.

Quote:

Plus didn't the N64 have 4 megs of RAM, like the DS? It would be so much easier if I could run my code out of cartridge space and allow the game to use the full 4 megs for data.
Is this possible?

The N64 had execute-in-place like the GBA. However, the N64 didn't have the extra near-megabyte of VRAM that the DS has; it had integrated EWRAM and VRAM like the Xbox, Xbox 360, and low-end PCs.

Quote:

Just at the moment for some levels there's not enough RAM so I just normally roll without texture maps.

Nintendo's N64 and GameCube games use Gouraud shading on a lot of the geometry. Would it be possible to designate some polygons as solid color and not load their textures?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

simonjhall wrote:

Oh and I've seen Quake on the PSP - it's good! Did you use the software renderer? Shame there's so much lag on the LCD! The DS doesn't seem to suffer from that problem. Just a crappy framerate!

Thanks :-) Chris Swindle did some great work on the networking side too. I basically just hooked up the video, input and sound.

Shame most PSP sites only link people to a really old port that Pacmanfan did which doesn't have sound...

Anyway, we just use the original Quake software renderer, although we've both done some fruitless dabbling with hardware. I think we've both been too busy to get it done properly.

The PSP's screen is big, but you're right, definitely not as good quality as the DS or DS Lite's screen.

Looks like you don't need any help with the DS version, but give me a shout if you have any questions about the how we did the PSP version.
_________________
http://aaiiee.wordpress.com/

You could probably scale all the textures by atleast half, it wouldn't be that noticable on the DS anyway.
As for memory, on some cards you can use gba rom space as 16/32 megabytes of memory as long as you don't write 8bits at a time to it.
There is a compiler patch somewhere that dslinux uses to allow 8bit writes to the gba slot but I heard that it would never make it into devkitpro.

Since Quake 2 has higher polygon counts and also probably uses more resources for pretty much everything it seems like a good idea to start with seeing if you can get that to run well first.

Quake BSP:s are constructed to minimize over draw to aid the software renderer, but to make the best use of the DS hardware it would probably be best use the 3d-hardware and to make a new map compiler (all the Quake .map sources for the original game are available now) or a tool that converts .bsp files to something more suitable. The downside of that would of course be that you can't simply run all existing maps on the DS without conversion but I think it might be worth it.

Problem is, this John guy is making his port to be an exact port of the quake client, so it can play on real quake servers and use real quake mods... but for your port it would be nice to initially have just single player that WORKS on the DS, that would be faster to do then a true quake client on DS.

At the moment, my version of Quake should be compatible with regular Quake, and mp works fine. I could go to town on it and tear it apart but I'm just too lazy!

I've been Q2ing for the last half-day now and I'm pretty skeptical that it can be done with the amount of memory available to the DS. Here's why:
This is the stock memory breakdown for Q1: (hope the text layout works...)

Code:

code and static data 600k
stack 100-200k
graphics + etc 500-700k
heap 8192k

So in order to get something onto the machine you need about 1.5 megs free before any models get loaded. This leaves about 2.5 megs free for the 8 megs of heap and the huge stack! I got rid of the excessive stack and got it to work with just 2.7 megs of heap. It now runs, mostly.

Quake 2, however, does stuff differently. In Q1 all model loading is done with malloc (so if your model is 1234 bytes in size, it'll allocate something like that). With Q2 everthing (as well as model loading) is done statically, and it's geared for the worst case. If your model is 1234 bytes in size, it'll use a block thats 16 megs in size! You can reduce this size, but when you get a big model it'll obv break. It'll take some work to get rid of all this static lark...

As everything's done statically my original Q2 executable required over 9 megs of RAM (600k of which is code). I've now shrunk that to 3.9 megs, leaving just 100k for...models, texture maps, stack, lighting, frame buffer :-)

Loading the level used in the demo then required over 3 megs.

I don't see this working without some kind of RAM card or using virtual memory. Anyone wanna donate?

Oh and thanks for all the interest in this by the way!

Please release a binary? :(
_________________
http://licklick.wordpress.com

Lick wrote:

Please release a binary? :(

I guess I could just release a binary which played the Necropolis demo... just to see if your DS is good enough to play it :-)
Source code is one of the requirements of releasing a copy of Quake though, so I'd have to package it. But I'm still working on that!

Any GPL-y people out there gonna moan if I put an .nds?

simonjhall wrote:

Any GPL-y people out there gonna moan if I put an .nds?

I'm sure there are more than a few :(

I would just bundle the source up in an archive, I wouldn't worry about any docs or anything. But yes, it's a pain since the .nds would be rather small compared to the source archive.

I presume it's alright by the GPL to delete unused source files.
_________________
http://aaiiee.wordpress.com/

Even if you get Quake 2 to run you also have a polycount at least 1,5-2 times that of Quake. With two passes to get the lightmaps and the hardware limits I don't see it being possible to get more than 15 FPS (I guess that's still sort of playable) most of the time.

I shouldn't sound so negative when you're doing all this hard work... maybe it's just that I prefer the original Quake :)

I would most certianly be interested in seeing the binary and most importantly your modified source. I am *trying* to write a 'port' of perfect dark, but it would a whole lot easier if I could have some sort of engine, IE the quake engine to just port over graphics and level data, rather than writing a wholenew engine from scratch my self.

-shadow

man oh man. I would LOVE if you released a binary that demoed necropolis. I just want to see quake on me ds. I have a quake necklace and everything, I love quake to death.
_________________
fckgw

So I left my card reader at work today (no I didn't do it on purpose) and I'm having this file seek bug (which I would have a chance of fixing if I had my reader) and it's left me really wondering if porting Q2 to the DS is a feasible thing to do.

I've almost made it to getting something on the screen (I'm talking about the menu here) but RAM is seriously low. After powering on and running _start() and _init() and loading in text and bss etc I've got it down to needing just 3.3 megs of RAM. That may sound terrible, but it originally took a little over 9 megs! And the only real thing I've sacrificed is (network) compatibility with the PC version of Q2... (sorry!) So that leaves 600-700k for 16-32 megs of data! Once I've got the pak file tables in memory I've got about 200k free.

Yeah you may say that the N64 version got by with 4 MB of RAM but I'm pretty sure that the maps, models and textures were read from the cartridge space - something I don't think I can do with DS homebrew. Pulling the data from files is likely to be too slow.

Anyone have any suggestions here? Blindly trooping on trying to get it to run ain't gonna work for too much longer! The only thing I can think of is if someone lends me one of those cards which has extra RAM on it and gives me a dash of code as to how to read/write data to/from it I'm pretty sure I'll be able to get Q2 to work...
How much do those cards have anyway? Isn't it like 16 megs?

Quake 1:
This can definately be fit within four megabytes of RAM. And maybe it's best to wait until I'm in a state where I can release the code... Keep the faith :-D

Sorry back on Q2 again:
I was slightly wrong when I said earlier that the model loading allocates fat, static amounts of memory when it loads a model. I forgot that it didn't originally call malloc, it called some Win32/Linux/Irix functions which did some kind of virtual malloc. So if you asked for 16 MB it wouldn't really give you 16 MB, but when you started to use it it would throw some kind of exception when ran out of real memory pages.

Is there some way of doing this without an MMU? Cos that'd make fixing the model loading code a whole lot easier!

Not as far as I know.

If I recall correctly, Q2 allocates a big block of virtual memory (using VirtualAlloc on Windows) per model etc and allocates within that as required.

So you'd think that you could just replace the original VirtualAlloc calls with nothing, and replace the individual sub-allocations with mallocs. Unfortunately not so, as I believe when Q2 is loading files, it expects subsequent allocations to be contiguous.

Which pretty much means that if you don't have an MMU you have to allocate a big block up front, or rewrite much of the memory allocation and loading code.

Unfortunately it is id's (or just John Carmack's) coding style to statically allocate worst-case memory buffers, which is fine for PC but sucks for consoles and handhelds.
_________________
http://aaiiee.wordpress.com/

PeterM wrote:

If I recall correctly, Q2 allocates a big block of virtual memory (using VirtualAlloc on Windows) per model etc and allocates within that as required.

Yeah, that's exactly right!

Quote:

So you'd think that you could just replace the original VirtualAlloc calls with nothing, and replace the individual sub-allocations with mallocs. Unfortunately not so, as I believe when Q2 is loading files, it expects subsequent allocations to be contiguous.

That's what I thought too.

Quote:

Which pretty much means that if you don't have an MMU you have to allocate a big block up front, or rewrite much of the memory allocation and loading code.

What, are you reading my mind here?!

Maybe the homebrew community should start a petition for what we'd like to see for the DS 2 :-)
I'd like more RAM, an FPU and an MMU please.

---

Anyway, I've got a little tool I wrote for another architecture which allowed me to take any piece of code and allow it to run in barely any memory by treating the RAM as a software cache. I could rewrite it for the DS just to demonstrate that Q2 will run perfectly fine (albeit massively slow) on the DS with virtual memory instead of RAM...

to clarify the supercard has 32 megs of ram, im not sure about the m3 or anything else, i dont know anything about accessing it, and im dead poor so as much as i would love quake on ds i cant get you one :S

The SC and M3 do have 32mb of RAM and it is actually apparently pretty easy for bare-metal homebrew to use it... (As opposed to DSLinux, which requires a custom toolchain...)

Still, the memory on the SC and M3 is not ultra-fast, but it may be better than nothing...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

It's only useful if you can track down every 8bit write, if you have a large project it's near impossible.

Actually, from what I've read on the DSLinux forums that's not the case.

That IS the case with DSLinux, which is a different kettle of fish really...

Try asking the DSL devs about this, but last time I check with them bare-metal homebrew can actually use the extra memory without too many problems...

Why?

Because with bare-metal you don't need to worry about every 8-bit write. You only need to worry about 8-bit writes to the memory area provided by the SC/M3...

With DSLinux it's different because DSL is an OS and treats the main memory + extra memory as a single unified memory area. Thus, DSL needs to handle to 8-bit write problem or else suffer complete failure...

An approach for normal DS homebrew, however, would be a bit different. You would use the main memory to store program code and immediate data while the additional memory is accessed as a special cache via a read/write wrapper that ensures only 16-bit writes occur.

This is possibly a bit of an oversimplification, but I've checked on this with the DSL devs in this thread
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Even with a read/write wrapper, you still need to track down all the 8-bit writes in order to place the wrapper. So Lazy1's statement still holds. He should know, he was trying to use the extra RAM for the mini vmac emulator thingie.

You'd probably want to concentrate on one or more subsystem, textures for example, and rewrite those parts to use the extended memory.
_________________
"no offense, but this is the gayest game ever"

As far as I know 8bit reads are fine, so you could copy the map, all the textures, sounds, ect into GBA RAM and read them from there with no problems.

Since the actual map data won't change at runtime, there will be no need to fix the 8bit write issue.

Good point lazy1...

simon, this could be useful for you, as I'd imagine the extra ram provided by the SC/M3/G6 is probably somewhat faster to access than the SD card...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

If you need money I suggest opening a paypal account and asking for donations, I did that and thanks to the generous donations of a few people I bought a Supercard and was able to add flashcart support for mini vmac.

If Q2 needs extra space for loaded data, and that data is never going to be over 32MB (including program code), and never going to be overwritten, it might be possible to simply use a GBA flash cart. This allows more devices to work (all slot 2 devices that support non-multiboot GBA ROMs) and is well established technique on the GBA (Tepples even wrote GBFS to make it simpler to do).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Heh heh, here's a sneak preview of things to come :-)
[Images not permitted - Click here to view it]

And I've got a whole 100k free! Wooh! That was painful. And now I can't get the pad to work, so I can't test out the menu system :-(

EDIT: oops, I don't have 100k free. That was how much was free before loading the menu images. I didn't have enough to load the console background image, so I must have about 30k free. Yeah.

Last edited by simonjhall on Fri Dec 01, 2006 1:08 am; edited 1 time in total

Please, you can't just leave us detail-hungry programmer types in the lurch! I'd love to know where you shaved the bytes off!
_________________
http://aaiiee.wordpress.com/

Wait, did I miss the part where you released Q1? Please finish that one first :) (It's my favorite...I have the first few levels memorized by heart)

PeterM wrote:

Please, you can't just leave us detail-hungry programmer types in the lurch! I'd love to know where you shaved the bytes off!

In order to get it down to this amount of memory I have two versions, one of which runs on a machine with more than four megabytes of memory :-) Most of the extra memory required (remember I said that it originally required 9+ megs static data) is for rendering in the absolute worst case. So I just kept dropping all the buffers until I could fit the executable into ~3 megs, but still ensure that all the demos ran.
So no models are being loaded at the moment (as I've got so little memory free), but I do have enough memory to do the rendering. What I've gotta do now is to cook up some system of getting in the models, and it should then run file.
As this is gonna require some kind of fancy memory system I'm gonna hold off doing that for a while as I ain't got no cash for a Supercard! I'm thinking about doing a VM system in the meanwhile just to prove that it works.

Quote:

Wait, did I miss the part where you released Q1?

I'm working on both at the same time, but I just wanted to make that final push in order to get Q2 onto the machine. As I've gotta work a miracle if Q2's gonna get further, I'm now gonna concentrate on making Q1 for DS better.

I love you.

I've fixed most of the memory related loading bugs now and I can afford to run with the full-quality textures and lightmaps on most levels now. So here's yet more pictures to tease you!

What the pictures don't show however is just how good the image looks on the top DS screen - there's a slight softeness to the LCD which makes most games look really nice, and Quake is no exception. Shame the framerate sucks :-(

[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]

I've just noticed that I got my camera so close you can see the grid structure of the screen! Sorry...

Thats freaking sweet!
I can't wait to frag those bastards with my nine inch nails :D

Is multiplayer in the future? Sound getting streamed to ARM7 or are you working on the engine/alloc/FPS atm?

Full version/demo? sweet krispy jesus this is awesome :D
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia

Looks fantastic, thanks for posting!
_________________
http://aaiiee.wordpress.com/

Good work, but you have to use every single hardware chip on the DS to make this run nicely. I'm talking about simple things like the div/sqrt accelerator to frustum tests and 3D rendering.

Mrshlee wrote:

Thats freaking sweet!

Thanks very much. I can't wait for this to be properly playable...

Quote:

Is multiplayer in the future? Sound getting streamed to ARM7 or are you working on the engine/alloc/FPS atm?

I took out the networking code last night, as I didn't have the space. I intend to put it back at some point, but having full compatibility with the PC Quake wastes lots of memory. I was considering ripping out all the sound stuff too, but's pretty integral to the game so I don't think I will. I've also never coded sound *in my life*, so it's pretty low on my todo list!

And yeah, I'm aware that I'm gonna have to really use the DS hardware in order to get some killer speed. John's already mentioned how the poly limit is a real factor for his hardware-rendered version, so I'm considering a semi-hardware-accelerated version by extending the software renderer with some hw-acc'd 2D/3D love. Doing the transformations and clipping in software isn't *that* slow, but the actual drawing bit really slows it down, as this is where all the texturing is done.

ot: here's me in Las Vegas! It was pretty cold there, so those girls must have been freezing!
[Images not permitted - Click here to view it]

Looks great so far!
Did you set the display size to 256x192 or are you scaling down from 320x200?

Also, you might save memory by reducing texture sizes by half or so. On the DS screen you wouldn't really notice anyway.

seriously amazing work. You should show this to a DS dev house, I bet you could get a job easy.
_________________
fckgw

Verry nice, could you post a video of the qauke with textures (if you have time)

Multiplayer would be awsome , even if it's only ds to ds (still it would be greate if it's compatible with the pc version)

But hey , first single player.

Please set a donation on your website, so you can get this supercard.
I think there will be enough people that loves to give some fee to get this quake to work

(i prefer quake2 > quake1)

Lazy1 wrote:

Did you set the display size to 256x192 or are you scaling down from 320x200?

It's 256x192. This causes lots of problems however as Quake expects the minimum screen width to be 320, so lots of the 2D drawing functions cause memory-access faults as there are plenty of hard-coded constants... The menu doesn't fit on the screen either.

Quote:

Also, you might save memory by reducing texture sizes by half or so

I think this will be essential for the hardware-accelerated version as doesn't the DS require textures to be of a certain size? Dunno how that's gonna work-am I gonna have to write a tool to allow people to downsample their pak files or should I do it when I load the textures into RAM? I'm obv not gonna provide a copy of my own pak files...
I also don't think the DS supports mipmapping, so that'd save some more memory.

Quote:

Verry nice, could you post a video of the qauke with textures (if you have time)

I just tried to record a video with my webcam, but as it's fixed focus it looked a bit shit. I could use my regular camera as that has a macro mode, but the batteries would probably run out whilst doing it!

Multiplayer itself does not require lots of memory (lets say 20-30k, including code) but compatibility with stock versions of Quake does. If I can't make it compatible and still fit inside the memory budget I could just change a few constants and build a new DS-compatible version for the PC. How does that sound?

And I now have a donations link in my signature :-) I need to get a card which has extra RAM. I've heard that the M3 has faster RAM than the Supercard, so I'd choose that one. Do they both have the same amount of memory? Looking through the Moonshell source seems to imply that the M3 has 'only' 16 megs, but the regular Supercard has 32. Does anyone know if this is true? And for those doubters, I'll say this now: there's no way that Q2 will run without extra memory. Whether that's real extra memory, virtual memory on a disk or some kind of ROM.

AND:
I tested out my semi-hw-acc'd idea last night, and it works great! All the clipping and transformation is done in unoptimised C, but then the rasterisation and Z-testing is done by the DS' 3D hardware. It's still untextured but it's SO MUCH faster than doing it all in software! It's easily five times faster than before, in fact I've seen it go over 25 fps! (and no, I'm not staring at a wall...)
_________________
Big thanks to everyone who donated for Quake2

M3 and SC both have 32MB of RAM (excluding SC rumble and M3 pro). You might need to switch modes everytime you want to access FAT or RAM but it's technically possible, dslinux does it.
_________________
GTAMP.com/DS

Ok nice

Didn't realize that you lived in England. I was going to send 5$ (real money lol) so I gave you a rough approximate for 5$. Any way keep up the good work, and I hope you get enough cash for that card soon. How much you got so far? and how much do they cost over there in jolly ol' England?

-shadow

On a side note, I was reading the Beyond3D article about the clever fast InvSqrt() function from Quake 3 and it was mentioned that Quake 1 feature a lot of assembler code specially optimised for the x86 architecture.

Have you encountered this stuff yet? What do you plan to do about it? I'd imagine that x86 optimised asm is not much good on an ARM :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Original Quake had two renderers, one written in C and another in x86 assembly. The assembly version was twice as fast IIRC.

Wow, strangers giving me money! Awesome! Though seriously, thanks very much - it really is appreciated. Hopefully I'll have enough to get a card by Christmas so I can kill time Q2-ing whilst hung over! Come on people, open your wallets :-D
And yeah I live in England, and no I don't have one of those awful fake-English accents that English people on TV shows in the US seem to have. Helen Baxendale on Friends, I'm looking at you!

Re: the renderer, I've not yet seen any square roots or inverse square roots. There's lots of reciprocals though, so they're hopefully candidates to optimise. I tried (quickly) to get the hardware to transform the image (instead of doing on the CPU) to remove all those divides and it was hardly faster... Hmm.

And yes, the Q1 and Q2 source that I have has three renderers, the plain C one, the x86 one and the OpenGL one. Q2 also includes glide I think... Suffice to say, there are a lot of #ifdefs! Btw 95% of the CPU time on the DS is spent in the (software) renderer.

Although the x86 assembler is no use on the DS, it does give me a hint as to where the most CPU time is spent as they've obviously optimised the slow bits. I may rewrite those bits in ARM asm but as there's no FPU or vector units there may be no point.

Also, it's been said before that the poly limit may be a problem. So far I'm nowhere near it! One of the advantages of doing all the clipping on the CPU :-D
_________________
Big thanks to everyone who donated for Quake2

Some people are asking about a website of this dev game.

Is there any website yet ? :)

I think it would help donating

greetz

No website, and I'm too lazy to make one.

I also have no DS now as the thing just died! I went to load a level and the thing just cut out. I was plugged into the mains at the time and the charging light went out too. If I unplug and replug the charger the light will stay on for like a second and then go out.

Any ideas?! I still have the receipt but it's pretty faded...
_________________
Big thanks to everyone who donated for Quake2

A lot of stores can do receipt lookups if you bought it with credit or debit.

As for the website, I can set something up for you; a simple blog or something + free hosting. I can even hook you up with CVS or SVN if you need, just send me a PM.
_________________
FireSlash.net

Assuming NOE's web site matches NOA's, if the DS is less than a year old, try looking up its serial number on Nintendo's web site; it should still be under warranty.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I'm sure I've seen the problem you're having mentioned fairly regularly in the Equipment section. If I recall, it's something to do with a blown fuse, which can be replaced...

Also, the InvSqrt() function I mentioned was in Q3, not Q2 or Q1 (As far as I know anyway...)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

I blagged a new phat DS by taking it back to the store with the most faded receipt in the world (I spent ages with an artist trying to enhance it to no avail).
I'll be back developing once I get it flashed...

EDIT: there's now a Quake blog (see sig). It'll be updated once my new kit gets flashed. Keep giving me money, people. Or even hardware...?
_________________
Big thanks to everyone who donated for Quake2

wouldnt you stuff run in an emulater?

Probably not, since there are still a fair number of things emus don't handle well...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Ant6n wrote:

wouldnt you stuff run in an emulater?

huh?? why would you want to run DS Quake, in a DS emulator, on your PC? Why not just run the original quake for PC?

josath wrote:

Ant6n wrote:

wouldnt you stuff run in an emulater?

huh?? why would you want to run DS Quake, in a DS emulator, on your PC? Why not just run the original quake for PC?

I think he meant for development reasons, given the context of the whole "DS Phat hardware exchange and now I need to install flashme" bit.

@simonjhall:

Quote:

I'll say this now: there's no way that Q2 will run without extra memory. Whether that's real extra memory, virtual memory on a disk or some kind of ROM.

You say it would NOT be possible without Extra Ram ? Would it be possible on the Gbamp then, or not ? (I just ask, because I wonder why Doom is playable WITHOUT Extraram and Quake maybe not...)

Last edited by pas on Wed Dec 06, 2006 5:29 pm; edited 1 time in total

As the man said, Q2 is basically impossible without using the extra RAM on the SC/M3/G6 devices.

So no, a GBAMP is not an option...

Doom is playable because it's a much older game that requires less hardware-wise to run...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

how about using flat shading or really low rez when no ram is avail

OOPMan wrote:

As the man said, Q2 is basically impossible without using the extra RAM on the SC/M3/G6 devices.

So no, a GBAMP is not an option...

Doom is playable because it's a much older game that requires less hardware-wise to run...

Took the words right out my mouth! Ta man :-)
To confirm,
- Doom runs already and (I'm assuming) has the lowest memory requirements.
- Quake runs, although is right on the edge of the capability of the machine. If there's a RAM card present I may choose to use it. I'm not expecting for it to be required.
- Quake 2 will not be developed further without extra memory. It'll be a requirement for the game, sorry. Squeezing 30-50 megs into 4MB isn't really doable!

And I did consider using an emulator but I'd have to do something about the disk access. Plus I like my debugger - I'd be lost without it! More importantly I'm using the DS' hardware now so it'll be crucial to work on the target hardware as I'm already finding gotchas with the graphics hardware (which I'll talk about properly at a later date).
_________________
Big thanks to everyone who donated for Quake2

Quote:

Want to see Quake2 for the DS? Then get me a Supercard/M3: Donate!

I want to see the first quake working before donate ^^, but if quake run, i think i donate some money like ten dollars to thank you.

So have a good chance with the port of quake :D, i keep adress of this topic on my bookmark

@simonjhall:

Would streaming the data out of the CF card (FAT Reading) be to slow ?
Do you need the 32 Mb RAM Cause of this ?

Reppa wrote:

I want to see the first quake working before donate ^^, but if quake run, i think i donate some money like ten dollars to thank you.

Of course, that makes complete sense. Lots of people start developing projects only to not finish them. You'd be pissed if I took your money and ran!

Quote:

Would streaming the data out of the CF card (FAT Reading) be to slow ?

It's very likely. It'll run and I'm thinking of writing it anyway to prove that it works, but it won't be playable.
I'm worried about the potential overhead of having to use these cards anyway, but at least you have the option of doing DMA or 32-bit reads (ie it's gonna be easy on the processor). But if you're using the disk reading/writing then the processor gets tied up whilst this is going on. Yes I know there are two processors.

I actually did something similar on Quake 1 back when memory was super tight and it made the thing go < 1 fps. That's doing (software) rendering and about 500k of disk access per frame. If you were doing 10-20 megs of access per frame it'd totally wail on yo' ass.
_________________
Big thanks to everyone who donated for Quake2

Wow im amazed at the progress your making, keep it up! Please! Anyway i have a question, are you eventually (after the first release or so) going to make the quake1 port able to use the 32 megs of ram to increase fps and overall performance? (after you get a supercard/m3 of course...) This would be usefull for online play, seeing as those can have bigger maps and can get pretty crazy with action.

This is really exciting! (Quake 1) :D

Do you think you will get good performance if you recode everything to use the DS' 3D hardware - and is that your plan?

Do you also plan to add network compatibility at some stage? Being able to play against PC users as well other DS users would be simply amazing! :D

Keep up the awesome work!

I'm not currently planning on using the extra RAM with the running of Q1. What I mean by this is I may use it to improve level loading speed (by caching pre-loaded models) but I don't want to use it whilst the game is actually being played. Using this memory will be slower than using the regular stuff so it's only gonna reduce the framerate.
It is still to early to tell though.

Quote:

This is really exciting! (Quake 1) :D

Tbh I'm starting to feel with Q1 that the finishing line is nearly in sight, plus I'm getting really bored of seeing the necropolis demo. I'm much more excited about Q2 though as it's a much harder problem and it'll be all the more rewarding once I know people are playing it on the DS' at 60fps!

Quote:

Do you think you will get good performance if you recode everything to use the DS' 3D hardware - and is that your plan?

It won't look as good as the software-rendered slideshow but the performance will be way better. I'm currently in the middle of converting all the rendering to using the 3D hardware and the frame rate is much better.

Quote:

Do you also plan to add network compatibility at some stage?

There used the be networking code but I took it out as I needed the memory. It will be back, and yes you'll be able to play against other DS'. PC compatiblity is not guaranteed.
_________________
Big thanks to everyone who donated for Quake2

First I want to thank you for what you are doing!
the first time I saw metroid prime hunter demo I had a dream: playing quake1 on my ds with wifi! and it will certainly become possible (thanks to you).
If you want the point of view of a big quake fan, i would like to say couple of things:
-i think playing regular levels with monsters etc..is cool, but I would prefere playing online against ds or PC with a sort of quakeworld port.
-when playing online, we don't need textures (every quaker disable them), maybe it could reduce the use of ram and help to implement network
-why is it difficult to have PC network compatibility? quake on a ds and on a PC doesn't speak the same protocol?
-is it possible to have the same control as metroid prime hunter? i mean strafe moving. And i think its difficult to find a good buttons configuration to make rocket jumps with a ds :)
maybe if we could setup our own button to an action it could be interesting. Or script rocketjumps :p

keep up the great work!

Every Quaker disables textures for online play, eh? Sad...

Gah, I feel a rant coming on, but this is neither the time nor the place...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Me too :-)

Personally I only play single player, and I keep all the textures. So that's one vote against that (silly) suggestion!
_________________
http://aaiiee.wordpress.com/

Ok, hands up who'd like texture maps? No takers, oh ok. That'll save me some effort.
_________________
Big thanks to everyone who donated for Quake2

i like pictures of kittens...

uuhhh... spam?
anyway i play online ind ive never talked to people who disable the textures, ive heard of people doing that for like big competitions though.
i think for the control it would be great if we could bind them ourselves, like make aliases for the buttons, as well as a double tap and maybe add a few designated areas on the touch screen for buttons, in the corners of course. anyway that way we could use the normal bind syntax: /bind <key> <action>

I like the idea of being able to set certain parts of the touch pad as different buttons, eg to change weapon. And I've been thinking about how to allow people to change buttons as I don't think adding new stuff to the Q menu is as easy as you'd think...

And I've only played Metroid a few times, so I can't remember how the controls are set out. I do remember getting cramp in my hand though! Anyone wanna describe the different layouts you can select?

And I've got my new DS flashed, so we're back Quaking again. Neil, thanks again - expect a few .nds files in your mail tomorrow :-) I've messed around more with the hw rendering over the last few hours I forgot just how awful parts of the code are... (ie the Q software renderer) But here's a bit of juicy hw-rendered action, I just got capped by the bad guy in front hence the screen is rotated.
[Images not permitted - Click here to view it]
I've shaded the image here with the z-buffer as I'm trying to figure out how the texture and light maps are arranged in memory. The models are full-bright white as I've not yet managed to figure out how to get their z info.
The alias models also are really slow to render, almost as slow as the world itself. Deep huh?
_________________
Big thanks to everyone who donated for Quake2

You resisted Lite, quite a performance! ;P
_________________
http://licklick.wordpress.com

Dood77 wrote:

anyway i play online ind ive never talked to people who disable the textures, ive heard of people doing that for like big competitions though.

strange, personaly i ve never talked to people who do not disable them with the picmip command, maybe because i already made some (not so big) competitions or played too much quake3.
Well to make everybody happy the solution would be to enable the picmip command, like that some ppl could play with textures and other without :)
as far as I remember i controled metroid like that:
left/right arrows = strafe
up/down = move forward/back
L = fire
stylus = change the X Y view (mouse_look)
double tap on the touch screen = jump
i think thats a good configuration to move arround someone (with strafe) but its impossible to strafe jump or rocket jump...well i don't think it would be easy with a ds :/

Right, [rant]

I think this disabling the textures stuff is utterly pathetic. It's partially a performance wank, but nowadays it's more of a cheap advantage wank.

I can understand why some people do it. After all, a textured model stands out very very nicely against play polygons, making it easier to target.

I suppose it's marginally acceptable if all the players in a game agree to do it, but I think it's basically a low-grade form of cheating in those cases where some players play vanilla and others disable non-model texturing to gain a cheap advantage.

Seriously, it's a game. If you're taking it so seriously that you'll disable certain textures to gain a cheap advantage then you're obviously taking it waaaaaay to seriously.

[/rant]
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

OOPMan wrote:

Right, [rant]
Seriously, it's a game. If you're taking it so seriously that you'll disable certain textures to gain a cheap advantage then you're obviously taking it waaaaaay to seriously.

sorry, maybe thats just because i love this game :(
if enabling/disabling textures is an option, thereis nothing to debate, everybody will be happy :)

not that oopman was suggesting simon take out the ability to disable textures, just expressing his opinion. i too think its pretty rediculus, i mean whats quake without the pentagrams on the wall? anyway odea forgot to mention the touch weapon control:
upper left button is to select normal weapon, middle for missiles, and the top left is for all the other weapons: you hold it down then all your weapons appear on the screen and everything else fades a little and you drag to the one you wanna select and let go, plus the bottom-right is for alt-form but obviously thats a specific metroid function ;)
and about adding to the quake menu, do you mean like the menu? or adding console script for new buttons? most quake source clients have custom menu features, fteqw is one of the most advanced. ever think of using the joystick support for input?

Taking out textures in mutliplay clearly is cheating. Funny story, though: We used to play in a LAN at someone's office and I always got shafted and had the worst computer. Fortunately in some custom made jungle level of counterstrike the textures were too much for the graphics card and so instead it displayed white walls. While everyone else had a hard time seeing me, I could pick off those terrorists quite easily. Some other time The textures of the walls shifted to the side when I was strafing, so I could see the guy behind the wall and shot him with my (virtual) assault rifle.

These were just bugs, but if it's done on purpose, I and all of my friends would consider this to be cheating.

Yeah, I reckon texture-less gaming is cheating, but I don't care as long as it's not me who's getting cheated on... So I'll see what I can do about a texture-less build. What would you like to see instead? Are you talking about gaming with the r_drawflat option turned on? Cos the poly colouration used for that is a real hack. Shading with the Z like in the above picture isn't free either.

And regarding controls, at the moment I have the bottom screen controlling the view and the digital pad controlling movement (like strafing). Firing the gun is done with the left shoulder. The right side of the DS is pretty wishy washy, and I'm gonna change those button bindings soon.

I'd like to add options to change the controls to the regular quake options menu, but this is non-trivial. I might just slap in some crappy DS menu (ie not properly integrated with the quake menu system) instead.

And I think the memory problems may be over now - dropping support for software rendering has left me with an epic 3.1Mb free! Now factor in the texture memory (512k) and I'm pretty damn happy. In fact I played through episode 1 last night in one sitting with *zero* memory problems, no cache thrashing - nothing! Time to try The Next Episode...

Oh and for a laugh I rebuilt in thumb mode to see what happens - I saved another 100k! But the framerate went down, so we're back in ARM mode for now.

EDIT: no, there's still cache thrashing on e2m1 and e2m2 (haven't tried any more) so I'm still too low on RAM. Shit.
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Oh and for a laugh I rebuilt in thumb mode to see what happens - I saved another 100k! But the framerate went down, so we're back in ARM mode for now.

Keep in mind that you can select instruction set on a per compilation unit basis. Consider putting the non-time-critical code in thumb mode. Another notice is that you sometime even get better performance in thumb-mode, due to better instruction-cache utilization. At work we're experiencing that in some cases (typically in tree-traversing etc).

sooo uhh, i dont suppose you wanna post up the bin that played episode 1 eh? cause even if the framerate is low, you can see that we're all drooling for something over here... also are you gonna have console access with a keyboard and all? cause that would be great, especially for making aliases and stuff, and binding our own keys to /say commands(rocket jumps, automatic weapon selection, that kinda thing...)

Keyboard access? As in over the network? Or do you want me to program an on-screen keyboard?

The more you ask for the longer it's gonna take...

off topic: yeah, I 'resisted' getting a lite. I tried to get one when I went to get my old phat replaced (and just pay the difference in price, ?10) but they said that I'd have to get the old phat replaced with a new phat then declare the new phat 'used' and I could get it upgraded to a lite for ?40! Uh, no. The screen on my new phat however is really really bright when I have the mains plugged in and in the firmware menu it allows me to change between four different brightness values - something my old phat wouldn't allow me to do.
_________________
Big thanks to everyone who donated for Quake2

It would be easer to set up binds, aliases, etc in various config files and then hack an extra menu that allows you to execute a custom .cfg file...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

That sounds like a pretty good idea.

If it were me (and a while ago it was!) I wouldn't bother adding any additional features at all, until the game is up and running. Lots of additional stuff can be added by editing the config file manually if desired.

Also, if the buttons are mapped to Quake "keys", people can remap the controls easily enough using the Quake options menu.
_________________
http://aaiiee.wordpress.com/

PeterM wrote:

Lots of additional stuff can be added by editing the config file manually if desired.

Yeah, why can't you just set it up the way you like on the PC and use the config file from that? That's what I'm doing...
_________________
Big thanks to everyone who donated for Quake2

At the moment the problem with the custom menu idea is that libfat under dkp r19b can't list files, so you'd have to use one of the hacked gba_nds_fat libs :-(
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Err...listing files? Plus I'm using gba_nds_fat rather than libfat.
_________________
Big thanks to everyone who donated for Quake2

No problem then :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Dood77 wrote:

sooo uhh, i dont suppose you wanna post up the bin that played episode 1 eh?

Ok, I give in - I've got an nds in the sent items of my inbox which pretty accurately demos where I'm at.

IF A FEW PEOPLE would like to get a copy of a pre-pre-release version then please PM me and I'll send you a version within the next few days.

By doing this you're aware that you're just getting an nds and nothing else. I'd just like to see what people think :-) I'm still not looking at the performance, I'm just trying to get the hardware-rendered version properly functional, and the current version...isn't too functional :-D
You also promise not to criticise, eg "OMG TEH FPS SUXORS!!"
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

please PM me and I'll send you a version within the next few days.

I am pretty sure your inbos will explode soon :P

Anyway did you think about reducing texture size to cope with ram problems? I don't think the DS needs the same full blown texture size that you need on a PC as of the reduced screen size. This might even be a more valid option for Q2. Even thought this might destroy networkplay with PC's. Still I personally don't think that netquaking DS vs PC is a fair game and thus should not have a priority. Cause even though controls on the DS are pretty cool I don't think you have a chance against someone playing with mouse/keyboard on a PC.. DS vs DS will rock, though :D

simonjhall wrote:

By doing this you're aware that you're just getting an nds and nothing else.

Keep in mind that refusing to give out the source code to anyone that obtained the binary is a GPL-violation. ;)

Before you send it to them, make them agree to not ask for the source code.
Even better yet, don't give in and let them wait for a finished product :)

Lazy1 wrote:

Before you send it to them, make them agree to not ask for the source code.

This won't legally help. The Q1 source release is released as GPL, and you cannot change that by having the users agree.

And don't get me wrong, I don't think any of this will matter the slightest bit here ;)

Ok ok, the only reason I suggested it was to stop people bugging me!
You can rest assured that a proper released version will come complete with source etc, it's just that packaging everything up properly takes time. Time which could be spent coding!

Oh and most memory thrashing problems have now gone, although after I rewrite yet more of the model loader it should almost disappear. I have gotta look at rewriting the model renderer however as it is sooo slow - if I run the game without models it's easily twice as fast!

And back on the texturing thing, I'm thinking about dropping mipmaps level 0, 2, & 3 and keeping level 1. This will reduce massively the amount of texture memory required and can be easily done with no changes to the pak files. It will however mean the texture quality will go down. The other option is to preprocess the (level 0) textures in the pak file (on the PC) and compress them into the DS texture format. This would use the same amount of memory as the level 1 textures but it'd be four times the resolution. But it'd require modifying the pak files... Hmm.

And @Mel, you're right - PC vs DS - who's gonna win?!
_________________
Big thanks to everyone who donated for Quake2

Here is what you could do to not modify pak files:
When it's looking to open a texture, see if that file already exists outside the pak file.

what i meant by keyboard was a touch screen keyboard of course :P
and no i dont expect you to put every little feature in the first release, that would take forever... as for ds 2 pc, it would be a fun feature, especially for co-op and lan with friends...

MelGibson wrote:

Still I personally don't think that netquaking DS vs PC is a fair game and thus should not have a priority. Cause even though controls on the DS are pretty cool I don't think you have a chance against someone playing with mouse/keyboard on a PC.. DS vs DS will rock, though :D

after thinking a little i am agree with that too. as ds vs pc is not fair and will not be fun for the ds player (maybe for the pc player too).

Patching with a PC tool is the best way - a little patching goes a long way
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia

Lazy1 wrote:

Here is what you could do to not modify pak files:
When it's looking to open a texture, see if that file already exists outside the pak file.

Isn't it even so that the quake resource system allows you to use both a data-dir and a pak file as the same virtual file system? If so, you could - as Lazy1 says - just look for textures in a native-format, and allow people to just add them to a data-dir. Yay, no pak-modifications needed, yet a 4x texture resolution increase. Perhaps you'll even be able to fit in more mip-map levels? (Or does the DS even support mip-maps without cpu-intervention?)

If you make mip-map levels a data-set feature (think D3D DDS file format), people can tweak this themselves. Wouldn't that be cool? ;)

Wouldn't that result in redundant data on the old storage device? Obviously that's not a huge issue, but if you're reducing the texture size surely it'd make more sense to get rid of the physically larger textures as well so as to save physical space as well as memory. The pak specification's fairly well known, and even if it'd mean opening the paks, taking out the textures, resizing the images, then adding them back in I think I'd do it for the space saved on my SD card. I'm nowhere near profficient enough a programmer to do this, but I'm sure it'd be plausable to knock up a command line extractor->resizer->re-pak program or whatever.

textures are stored in the bsp file not as separate resources in the pak file. It is probably not a good idea to modify the pak files. I better solution would be to do something similiar to the way the pc glquake handles mdl files. it creates its own subdirectory to store gl friendly tri-strip and tri-fan command lists and is hard coded to build/look for files there.

re: the texture packing problem, these are all good suggestions - I just need time to try them out!

So I've been busy making this thing faster as I thought I'd take a break from texturing. So for brush model (ie world) rendering,
- the bsp clipping is now faster than before
- the polygon clipping is now faster than before (still needs to be way faster though)
- the polygon transformations are way faster now, and more is done in hardware
All in all, the world rendering stuff is 30-50% faster than before! The bit where I submit the geometry to the DS hardware and it actually rasterises it is really fast. I'm getting 20-30 fps in a lot of places.

The entitiy (ie Alias model) rendering is still slow, that's the next thing to fix.

But whilst doing all my timings for improving the brush model rendering I noticed something else - when the game is paused and and nothing is being rendered it runs like lightning (60 fps+), but when the game isn't paused (but still nothing is being rendered) the speed shoots right down on certain levels. I just spent a little bit of time looking it up - and it's the physics system! It's often as slow or slower than the rendering.
Ah ha (I though), that'd be easy to fix with a little bit of float->int craftiness, but no I actually discovered the Quake C virtual machine :-( It's basically a simple CPU emulator (ie it decodes opcodes). As I don't have access to the original Quake C code this is gonna be really hard to float->intify, so I really don't know what to do.

I could REALLY do with an fpu!
_________________
Big thanks to everyone who donated for Quake2

I'm sure you'd be able to get the QC source, as it was used in a lot of mods...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

If you plan on doing lightmaps using the surface cache a la VQuake, removing the mip maps would likely increase memory usage because every poly needs a unique texture.

Edit: The original QuakeC source is available...

Is this the QC source you need:
ftp://ftp.idsoftware.com/idstuff/source/qcc.tar.gz

Wow keep up the good work !

Do you already have enough money for this supercard/m3?

(I'm still hoping for a port of duke nukem or shadow warrior. :) )

Thanks for the links. Although having spent a bunch of hours with it last night I've decided that adjusting the Quake C code is gonna be kinda pointless as I'd have to adjust the compiler too (although I'm thinking about that bit). Basically the instruction set for the virtual machine is like floating-point city - there's so few things that you can do with integers!
So I'm converting the cpu emulation to fixed-point, but this is (obviously) non-trivial. Hopefully once I've done this it should run a whole lot faster - sometimes the VM takes 100ms of frame time! It's become a real performance bottleneck.

Quote:

Do you already have enough money for this supercard/m3?

No, I'm miles off. Although I am ensconsed in Q1 right now, doing Q2 would make a nice change!
_________________
Big thanks to everyone who donated for Quake2

Ouch, damn that nasty little VM...

*Googles for "fixed point quakec"

Hmmmmm, apparently the people who worked on PocketQuake did a lot of FP hacks, so you might want to take a look at their source and see if there's anything of interest...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Now if only they just brought out Google Code... You could just ask it for a program and it'd go away and write it for you! The Star Trek TNG computer would be able to do it for me anyway.
And yeah I already looked at the PQ source (as I still had it on my HD) and it's not been changed, which I found really strange. But their source code archive was incomplete so maybe I've just not got the modified version.
_________________
Big thanks to everyone who donated for Quake2

Nobody seems to have asked this, when you have a finished version of Q1 is it going to support QC mods?

I guess that'll depend on how much has to modify the QC VM and so forth.

If lots of changes to the QC engine are made, a mode might require a recompile against QDS in order to work.

Also, memory constraints might be an issue with some mods, I'd guess...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

I'm not planning on changing the VM in such a way as to break it. I'm planning on trying out the Malice total conversion if I have the time (as I'm sure that I still have the CD lying around) but the thing which is more likely to break mods and total conversions is the RAM limitation...
_________________
Big thanks to everyone who donated for Quake2

I wasn't planning anything too extensive for mods. I loved playing single player quake with some of the weapons mods, and thought it would be cool to do this in the DS version too.

Are you planning on implementing a control interface similar to PocketQuake's with the touch screen?

I seem to recall simon is planning on having a Metroid: Hunters type of interface...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

so if you modify the quake c source does that mean no pc2ds play at all? :(

As far as I can tell, the Quake C code is run by the server. The client just sends commands back and forth and the server tells the client where stuff is so it can render it.
In a single player setup you run both the server and the client. When you're playing a demo you just run the client and no QC is run at all.
_________________
Big thanks to everyone who donated for Quake2

Maybe a cheap solution is to remove the server from the client and let the PC do all the work.
Of course that means you'd be limited to wifi range to play even single player, but it would be a lot faster.

Or maybe the QVM would run on the arm7?

Hi again - I've just checked my mail and everybody who's tried this (so far) with a supercard seems to have failed to get it to work...(as it can't seem to find the pak files)
I was having file access problems last night (with my gbamp) when I was getting the Malice TC to run, so maybe they're related.
So, supercard people - expect to get a bunch of debug builds at some point! We're not off to a good start are we?!

And yes, I considered putting the VM on the ARM7, but sometimes it's slow enough on the ARM9, so it'd be even worse on the '7. Still could be a good idea though.
_________________
Big thanks to everyone who donated for Quake2

I always have issues with my supercard and NDS homebrew. Poking through IDA at a dissasembly of its firmware makes it seem like the card was more designed for pirating than homebrew.... *shrugs*

In anycase, big thing for the supercard is putting the GBA loader in the top of the nds file. (dsbuild, and rename to .sc.nds) That way you assure that the program is loaded correctly. I had a lot of problems where my ARM9 code would run and ARM7 code wouldnt, and vice versa.

Also, with gba_nds_fat, don't forget to define SUPPORT_SCSD and SUPPORT_SCCF... I think in most of the versions I've seen, they werent enabled by default.

Hope this helps. Also, I have two Supercard Lites if I can be of any assistance, just shoot me a PM.

Cheers
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Juglak wrote:

Also, with gba_nds_fat, don't forget to define SUPPORT_SCSD and SUPPORT_SCCF... I think in most of the versions I've seen, they werent enabled by default.

Ah, that could be it. Where do I put these defines? I just built the files and added the header file to my app...
Still taking donations for supercards btw :-)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Juglak wrote:

Also, with gba_nds_fat, don't forget to define SUPPORT_SCSD and SUPPORT_SCCF... I think in most of the versions I've seen, they werent enabled by default.

Ah, that could be it. Where do I put these defines? I just built the files and added the header file to my app...
Still taking donations for supercards btw :-)

in gba_nds_fat, they are in disc_io.h, and you have to rebuild the lib after changing the header.

in libfat, everything should be enabled by default afaik (there doesn't seem to be any obvious places to enable/disable device support)

I was going to PM you, but then I read that all the other SC users were having probs, so I figured it probably wasn't necessary :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

simonjhall wrote:

Juglak wrote:

Also, with gba_nds_fat, don't forget to define SUPPORT_SCSD and SUPPORT_SCCF... I think in most of the versions I've seen, they werent enabled by default.

Ah, that could be it. Where do I put these defines? I just built the files and added the header file to my app...
Still taking donations for supercards btw :-)

I usually throw them in my ARM9 makefile, but thats me. I'm sure theres somewhere more cozy to put them where they would function.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

I found those defines, it works now - thank you very much! So yeah, it runs on the supercard now.
I was gonna use libfat but I've not yet upgraded my devkitpro. So I'm using the old fat lib so that I don't get the problems that I had with Q2. I'll use it eventually...

Oh and I've had a go with the Malice total conversion, but there's not enough RAM. The levels are up to a megabyte larger than the average level in Quake. It will probably require the RAM card in order to run. I can't be arsed to pursue Malice until then...

Oh and I've now gonna cook up a proper version which will play the game for the SC users. But I had my (second) work party today (we hit the bar at 11am) so I'm feeling exhausted from eight hours of solid drinking.

EDIT: I just made that new build and sent it out - now I'm def going to bed!
_________________
Big thanks to everyone who donated for Quake2

Great!

I do feel I should point out that, although the supercard has the 32MB of DRAM, you can not simultaniously access the DRAM and the SD card on a supercard SD (SCSD). I *believe* this is a similar case to the SCCF, but I do not own one, so, not 100% sure.

I don't think this should pose too many problems, but, if you're loading things out of the pk3 files to your "extended" ram from the SD, you'll probably need to load it to normal ram, then to the SC ram.

When you enable the SD card bit on the supercard, the addresses from 0x09000000 to 0x09FFFFFF become SD card related. (Not 100% sure what they ALL are yet, but, its definately not the DRAM). If done only by bit, the lower 16MB of the DRAM is still accessable at 0x0800000... but I believe gba_nds_fat sets the SC directly in only SD mode, where I believe the lower portion mirrors the upper portion.

I had documented the mode bits for the supercard somewhere, but alas, I cant seem to locate them.

Also, in every mode, there are a few bytes of DRAM used for SC control, which have messed me up in some travels loading > 16MB on the SC ram. Only about 20 bytes possible to mess up, but, its still an issue. They are all in the lower 128KB of the 0x09000000 area I believe.

Hope this is useful.

-J
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Figures, a few seconds after I posted that last reply, I found the info I noted about the SC mode reg...

Code:

SCMODE = 0 = Supercard Firmware located in entire 32MB address space (mirrored over and over)

BIT0 = 1 = DRAM enabled (all address space)
BIT1 = 1 = SD Card Address Space enabled (overrules 0x09000000 - 0x09FFFFFF)
BIT2 = 1 = DRAM Write Enabled
BIT3 = 1 = Override 0x08000000 for Rumble pack (Supercard Rumble only... which I dont think has DRAM?)

I think theres a bit that enables writing to the firmware, but, I'm affraid to mess with it. lol.

Heres the ASM code (from supercard_io stuff) for writing this reg:

Code:

@----------------void sc_mode(u16 data)---------------
   .ALIGN
   .GLOBAL sc_mode
   .CODE 32
sc_mode:
mvn r2,#0x0F6000000
sub r2,r2,#0x01
mov r1,#0x0A500
add r1,r1,#0x5A
strh r1,[r2]
strh r1,[r2]
strh r0,[r2]
strh r0,[r2]
bx r14

There we go. That should help.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

You could just load everything into supercard ram , and use it as a disk. I assume the binary plus the application are not going to eat more that 32+4megs of RAM?

-Shadow

Well, the full versions of Q and Q2 are much larger than 36MB, with levels, graphics, etc. So there would definately be a need for a filesystem somewhere outside normal addressable space.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Yo, I've been pretty quiet with this recently as I've been trying to get the pre-release builds working - seems there are problems when using pak files with the supercard...but I can't find out properly what's going on as I've not got a SC yet. They do work however when the pak file gets extracted to the file system though :-)
So now it's back to optimising the VM and doing texturing again...

Big thanks go out to my testers!

On with the show :-D
_________________
Big thanks to everyone who donated for Quake2

What version of GBA_NDS_FAT are you using? The one on Chishm's site has devices disabled for a reason, they don't work correctly.

I recommend the fatlib used in picodrive or use the one from REIN.
_________________
GTAMP.com/DS

simonjhall:
Another odd issue I have using the supercard, when reading from the SD... possibly a problem with the gba_nds_fat lib...

When reading chunks of files > 512 bytes, the library (or possibly the supercard, i havent determined which yet) seems to "fumble" random bytes... throwing off checksums, and other various things. I noticed this when trying to stream mp3's from the SD card in the supercard... if I did:

Code:

FAT_fread(blah..., 16384, blah...); // read 16384 bytes (i forget the exact syntax offhand)

... then sometimes the bytes would be messed up randomly. (well, not random, they were always the same for the same chunk... but not always in the same place and such in different reads... if that makes any sense).

But, oddly enough, if I use this method (much slower):

Code:

for(i=0;i<16384;i++) { *data++ = FAT_fgetc(file); }

... then the bytes would be perfect.

I suspect your having a similar issue reading the larger chunks of pk3 files...

I'm assuming this problem has something to do with sector boundaries... but I'm not certain.

Hopefully this helps.

-J

Edit: Note about the disabled devices in gba_nds_fat... I believe they were disabled for lack of write support...? I could be wrong.

I've been able to add write support for my Supercard Lite to gba_nds_fat using the supercard_io stuff on their site, with some minor modifications to make it actually work. (The zip on the site is somewhat incomplete...)
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

I'm using the version from his site; the latest is dated 3/3/06. As I've not got the hardware to test, I can't be sure where the problem lies. But it seems that it's losing the occasional byte from a file and so as a result everything after is shunted by 1 byte (so it breaks).
This still seems to be an issue when using the files individually, as well as using pak files.

I'm in the process of upgrading my toolchain at the moment so I can properly use libfat.

@juglak - you could be right there. Maybe I need to try and read files a byte at a time... I should really order myself one of these things so I can properly fix these bugs.
_________________
Big thanks to everyone who donated for Quake2

The new non-pak version works me me simon. Nice job :-) Good luck getting the performance up to pace :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

<excuses>You've got a pretty debug build there, so the VM definately chugs when you get near bad guys!</excuses>
I'm glad that it runs on your kit, though I still think there could be some file reading bugs though...
Oh and I guess you've noticed that there's no Z on the alias models, only the brush models - that's debug too! I can give you a fix for that if you like.

But yeah, gonna hafta make it faster...
_________________
Big thanks to everyone who donated for Quake2

I've seen some programs around here which have mp3 (or similar) playback. How much CPU juice do these sorts of decoders take on the DS?
I'd love to get the CD-audio playback going using something like this. Full CD-quality isn't essential though...
_________________
Big thanks to everyone who donated for Quake2

Most, if not all the CPU, probably. I don't have specific numbers, since I have no idea how you could even check how much CPU they're using :P

Moonshell has an MP2 decoder running on the ARM7, but that more or less uses all of the CPU power available on the ARM7. Maybe it could be improved with some optimization.

There's also the possibility of using Tremor (a fixed-point Vorbis decoder) in low accuracy mode and using relatively low bitrate files, like 64 or 80 (it sounds pretty good, actually). I don't know if you could get that running on the ARM7 though, nor do I know what kind of CPU requirements this has. I'm sure it could also be sped up with some good coding skills. If you futz around with Tremor, add -D_ARM_ASSEM_ to CFLAGS and remove -mthumb from ARCH in the makefile. You may be able to find some additional optimizations for it by examining the Tremor decoding code in Rockbox (the iPod has an ARM7), if stock Tremor is too slow.

There's just one thing to note: since the DS's sample rate is 32768, there's a little bit of hackery involved if you wanna use MP2 (Vorbis supports arbitrary sample rates, so there's no problem there).

You could also go with ADPCM, but that's icky and the files are large. :P

ADPCM at 32768 Hz mono is 131 Kbps, not too bad for encoding a whole CD soundtrack.

But with the standard IMA ADPCM supported by DS hardware, you will run into a slope overload problem on some waves, which can sound like clicking or clipping depending on the wave. I made an ADPCM codec called "8ad" with customized quantization tables to provide extra headroom at the expense of some hiss.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

It would be great to have the lovely NiN soundtrack rolling in the background :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

You could also use a less cpu intensive format, like wav with little compression, sure it would fill up a lot more space on the sd card, but you can keep it optional and hell, buying a dedicated sd card for quake is still cheaper than most commercial games are ;)

* sorry, read over tepples post which suggests the same thing...

tepples wrote:

ADPCM at 32768 Hz mono is 131 Kbps, not too bad for encoding a whole CD soundtrack.

But with the standard IMA ADPCM supported by DS hardware, you will run into a slope overload problem on some waves, which can sound like clicking or clipping depending on the wave. I made an ADPCM codec called "8ad" with customized quantization tables to provide extra headroom at the expense of some hiss.

how did you make these?

tepples wrote:

ADPCM at 32768 Hz mono is 131 Kbps, not too bad for encoding a whole CD soundtrack.

That'd be great, it doesn't sound like it'd need too much CPU time or memory to decode. I'm thinking about putting it on the ARM7 along with the wifi and sound. It looks like gba_nds_fat will let me run it on the '7, so I wouldn't have to pass the data across from the '9 - nice.
I'm going to have to extend the debugger to allow ARM7 debugging at this rate :-(
_________________
Big thanks to everyone who donated for Quake2

Texturing!
I've finally managed to figure out how to compute the texture co-ordinates of the brush models (ie the world and ammo boxes) and I'm dead chuffed. Basically, the designers didn't specify UVs like artists do today, instead they just decided how they wanted a texture map to be projected onto polygons. So I've gotta calculate my own UVs :-S

But I've done it now, and I've got the drunkencoders texture splatted all over the game :-D

It's not too hard now to actually use the real textures, plus whilst figuring out this texturing lark I also found out how to generate the UV co-ords for the lightmaps...
Oh and there's NO slowdown using texture maps!
_________________
Big thanks to everyone who donated for Quake2

Thats really amazing work. May I ask on which card you have it running ?
Concerning the sound.. maybe it would be easiest just to use 44.1khz WAV files at first as the overhead of computing these would be lowest imho, even though they take up most of the space.

Lack of slowdown is very cool :-)

Mel: Wouldn't a 22khz or 11khz file have less overhead?
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Hmm.. probably your right OOPMan. I wonder if there is any sound format which the DS supports out of the box ? maybe (AD)PCM ?

using the 3d hardware is probably a dead end for quake on the ds. the tri count is just too high once you start rendering the models. in addition the lack of a proper blending mode makes this difficult. you can use the frame capture to grab the texture frame then render the lightmap frame and blend them in software. but the mdls have way too many traingles. you could also render the mdls in software and then use the hardware to render them as sprites. also you may run into problems with the lightmap texture coords since the coords are too small for the 12.4 data type. you can use the texture matrix to scale the coords by 1/16th you just need to use a special flag when loading the lighmap textures - TEXGEN_TEXCOORD. best case scenario you get 30 fps - I would be surprised if you got more than 10 or 15 fps.

Au contraire: using the cpu to do all the rendering is definately a dead end for Quake on the DS. I can say with confidence that the *there is no way* that a software-only renderer can be faster than using the geometry engine, and so I decided to pursue the hw-acc'd route for that reason.

Have a little faith! I'm determined to get this thing running at a good framerate - as I've said before, I already I can get a cosy 20+ fps when just rendering the world with full-res textures (not running the VM) and I'm *well below* the polygon limit, even when rendering models! Perhaps there is also another near-free lighting option that you didn't consider... (hint: there is)

Now Quake2 - that's a whole different situation. Until I can get my hands on the required hardware I'm not gonna be able to properly tell what kind of performance I'm gonna get.

And to ye who have faith, I've not yet looked into the actual sound details yet. I don't know what format the sounds are in, and I'd rather not downsample them on the DS... But for the CD tracks that'd obviously be done offline so a more appropriate sample rate should be chosen then.
_________________
Big thanks to everyone who donated for Quake2

there is hardware blending but it does not have the right modes. yes, you could use the hardware lights or use per vertex colors - both would look awfull. Neither would would be anywhere near the quality of the lighmap solution. since the ds does not multitexture I am not sure that there are a lot of other options.

Well it looks like I'd just better delete all the source from my hard drive and go back to playing Mario Kart then. Anyone want to buy a used gbamp?
_________________
Big thanks to everyone who donated for Quake2

sorry not trying to be too negative. just pointing out that you have some intersting/difficult obstacles to overcome as I am rather curious to know how you are getting around them. I wish you the best of luck.

Ta man :-)
This project has taught me not to worry too far into the future. Whenever there has been a showstopping problem a solution has always presented itself. The fact that this has happened so many times now I've just stopped caring!
For a machine that was never designed to run this game, the DS is doing a damn good job of it.

So regarding performance and lighting issues, it'll be alright on the night :-D But I too am interested in how...
_________________
Big thanks to everyone who donated for Quake2

simonjhall: if you do with ADPCM, please use stereo for the music if possible, 'cause mono is just lame. :P Though, having to read 262 kbits every second might be too much for some CF/SD cards...

You'll definitely have to convert the sound effects on the PC to get the right sample rate and have it as ADPCM (8ad or otherwise). As for the sample rate, it should probably be either the same or half the sample rate of the DS's hardware.

Did you see my post about VQuake? The Rendition Verite did not have multitexturing. VQuake essentially stored the surface cache in VRAM. This seems like a very servicable solution for the DS.

Yeah, that's the same (or similar-sounding) as what the regular software renderer does. When I was still using the software renderer I found (obviously) that the larger the surface cache I gave it, the better the performance. But the thing is, this cache ate up a large amount of memory... I'll def have a go again with this method at a later date but I'm still worried about the memory usage.

Although...(the brain starts working)...I'll get back to you on this one!
_________________
Big thanks to everyone who donated for Quake2

keep on the good work !

if you'll have time, take some screenshots or create another video :p

greetz, and happy holidays!

The surface cache has to be in VRAM anyway -- I can't think of any reason to duplicate it in main RAM. The speed of VRAM access on the DS will be a blessing, as compared to uploading textures to a PCI card.

Quote:

The surface cache has to be in VRAM anyway

Yeah, that's what I was thinking, and having 512k of cache would be pretty awesome (I managed to get it to run with just 45k - the default is 256k!). Although that'd mean the texture maps would have to live in regular RAM (what RAM?!). Building the combined light/texture maps is still expensive though.

I'm still plodding on with regular texturing, and yeah I could show I video but I've got a palette problem and the colours look kinda mashed. Looks good with depth fogging though.

I'm also not so sure about downsampling the textures (like has been mentioned before) as it looks pretty crap, esp with the lack of texture filtering.

Oh and I just got another donation - yeah!
_________________
Big thanks to everyone who donated for Quake2

GLQuake can handle cards which can't multitexture, but by the sounds of it you're writing your rendering back end from scratch and not porting from GLQuake?

Also, getting Quake to fill a buffer with audio, which you can then send to a sound device is really easy. I'm not sure how the DS handles sound, but on the PSP, we did the following:

1. Set up an audio callback function. This thread's function gets called back by the system's audio thread whenever the hardware buffer needs filled.

2. When filling the buffer, we convert from Quake's 11 KHz audio to 44 KHz for the PSP, taking into account different buffer sizes, wraparound, etc etc.

3. We store a count of how much of the buffer has been sent to the hardware. This tells Quake where to fill up to when it's filling the buffer for us.

The PSP source is available here:
http://psp-quake.cvs.sourceforge.net/psp-quake/Quake/WinQuake/psp/sound.cpp?view=markup

Most of the complexity is due to the buffer conversion.

If with the DS you can get around "pull" method of the PSP (i.e. instead use the same buffer for Quake to mix in as you use for the DS to play from), you should be golden.

Sorry for the long rambling post!
_________________
http://aaiiee.wordpress.com/

That's definately helpful, and now we all know the sample rate is 11kHz :-)
Also, ta for the link to the source - your code is so much nicer than mine! C++ and everything! I haven't the memory for C++...

Ok, bunch of questions - by the looks of the change logs it seems you didn't change too much of the rendering or model loading - am I right? It's also nice to see what PSP homebrew source looks like, what with the reverse-engineered SDK! Did you ever try and improve the clipping and transformation by using the VFPU? And what kind of framerate did you get? Also, did you get far using the 3D hardware? (I miss programming the PSP :-S )

Back on sound, the thing I'm most not looking forward to is the ARM9<->ARM7 hoo-ha. I'm sure it's going to conflict with the wifi library...
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Back on sound, the thing I'm most not looking forward to is the ARM9<->ARM7 hoo-ha.

If you figure that out let me know, I've pretty much given up due to the complexity.

Excuse me, Peter, you're right -- It's not that GLQuake needs multitexturing, but on cards without it (including Voodoo 1), the renderer made a second pass with an alpha blended light map.

As for why VQuake used a surface cache, I forgot whether it was a lack of support for true alpha blended textures on Rendition chips or if it was just too slow for two passes.

I'd expect the DS rasterizer to be too slow to render the entire background twice, especially because multi-bit alpha textures absolutely murder the fill rate.

It would also double the poly count for the background, but that might not be as much of a problem for typical Quake 1 levels.

I would be happy with plain vertex lighting. Just sample the lightmap at the vertex position..

simonjhall wrote:

That's definately helpful, and now we all know the sample rate is 11kHz :-)

I'm pretty sure Quake can mix in whatever sample rate you want, you just need to tell it what your desired sample rate is and it'll mix appropriately.

simonjhall wrote:

Also, ta for the link to the source - your code is so much nicer than mine! C++ and everything! I haven't the memory for C++...

*bites tongue to avoid C++ flame war*

I pretty much *need* to write nice well commented code, or when I go back to it I don't know what the fuck I was talking about when I wrote it.

I usually write pseudo-code using comments first, then add the real code!

I'm just surprised that the code has been out there so long and nobody's hassled me for using a switch statement in my format conversion -- it does get optimised out, I checked!

simonjhall wrote:

Ok, bunch of questions - by the looks of the change logs it seems you didn't change too much of the rendering or model loading - am I right?

Yep, I don't think I touched that code at all.

simonjhall wrote:

Did you ever try and improve the clipping and transformation by using the VFPU?

Nope, I tried to do the bare minimum of messing with Quake's code.

simonjhall wrote:

And what kind of framerate did you get?

Somewhere in the region of 20, depending on scene complexity.

simonjhall wrote:

Also, did you get far using the 3D hardware? (I miss programming the PSP :-S )

I did some pottering, but barely past the stage of commenting out all the GL calls and unused fluff until it compiled. My plan was then to iteratively add in PSP substitutes for the GL calls until it worked.

simonjhall wrote:

Back on sound, the thing I'm most not looking forward to is the ARM9<->ARM7 hoo-ha. I'm sure it's going to conflict with the wifi library...

Yeah, I don't envy you there, that will indeed be the tricky part - Quake can probably do all the mixing and stuff for you.
_________________
http://aaiiee.wordpress.com/

Quote:

especially because multi-bit alpha textures absolutely murder the fill rate

Is that true? I know using alpha reduces the fill rate on modern video cards, but does that also happen on the funny 3D hardware inside the DS? I always assumed that it guaranteed that you could render X number of textured, lit, blended polys at 60fps... (or have I got the wrong end of the stick?)

Quote:

I would be happy with plain vertex lighting. Just sample the lightmap at the vertex position..

That's what I was planning on doing. Plus I have loads of polygon budget free, so I could easily tesselate the polygons that are drawn to increase the amount of lightmap data used. Plus aren't there hardware lights? I was thinking of using them (combined with vertex lighting) to do the dynamic effects.

Or for the dynamic effects I could just do what GLQuake does and plain not bother. Instead it just draws alpha-ed circles/spheres around the light sources. And no, I'm not porting the GLQuake renderer. I'm extending the software renderer and ripping out all the slow stuff as I go along. Kinda wish I had just taken the GL route, but doing it this way has allowed me to port a tiny bit at a time (so I can see it still works) rather than doing it the GL way and having nothing on the screen the first time I power it on :-) Also using the software renderer keeps me way below the polygon limit as all the clipping is done in (now fixed-point) cpu code.

Anyway, I'm still having texture palette problems so I've whipped out the software renderer (and upgraded to dkp 19b at the same time) and as I've got a proper handle on the textures now I decided to test how stuff looks at different quality levels. So here are four screenshots of the same scene with different mip levels: (with the sw renderer btw) (and sorry they look so dark and small - imageshack doesn't seem to like resizing gifs)
0: [Images not permitted - Click here to view it]
1: [Images not permitted - Click here to view it]
2: [Images not permitted - Click here to view it]
3: [Images not permitted - Click here to view it]
Notice the banding on the walls the higher the quality - this goes away when using all four mipmaps on the same scene. I reckon level 1 is pretty doable and the reduced quality isn't that noticeable. Hell even level 2 looks ok half the time but it looks quite poor on the near stuff (like pick ups). Here's some more examples on the Necropolis demo:
0: [Images not permitted - Click here to view it]
1: [Images not permitted - Click here to view it]
2: [Images not permitted - Click here to view it]
3: [Images not permitted - Click here to view it]
Shall I just use level 0 and then drop down a level on the levels I can't fit in memory? Or does anyone have any better suggestions?

Oh and Peter, the sound on PSP Quake was the first thing I noticed as I could hear the Necropolis demo running on someone's PSP :-D Very cool.

Man, this is one BIG post.
_________________
Big thanks to everyone who donated for Quake2

PeterM wrote:

simonjhall wrote:

Also, ta for the link to the source - your code is so much nicer than mine! C++ and everything! I haven't the memory for C++...

*bites tongue to avoid C++ flame war*

Hehehe, that's funny ;-)

simonjhall wrote:

Is that true? I know using alpha reduces the fill rate on modern video cards, but does that also happen on the funny 3D hardware inside the DS? I always assumed that it guaranteed that you could render X number of textured, lit, blended polys at 60fps... (or have I got the wrong end of the stick?)

Hmmmm, possibly. I think the DS has got the hard-lock on max poly's per scene to try and ensure that FPS is as close to 60 as possible at all times, but I think there's no guarantee on things really. Still, given that most DS games using 3d never have low FPS, it probably works to some extent :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

gbadev.org forum archive

DS development > Quake, yeah

#107263 - simonjhall - Sat Oct 28, 2006 3:16 am

#107267 - Lazy1 - Sat Oct 28, 2006 3:36 am

#107282 - tepples - Sat Oct 28, 2006 5:43 am

#107285 - sajiimori - Sat Oct 28, 2006 6:08 am

#107301 - OOPMan - Sat Oct 28, 2006 10:16 am

#107306 - simonjhall - Sat Oct 28, 2006 11:58 am

#107316 - OOPMan - Sat Oct 28, 2006 1:48 pm

#107424 - simonjhall - Sun Oct 29, 2006 4:24 pm

#107568 - simonjhall - Mon Oct 30, 2006 11:34 pm

#107571 - tepples - Tue Oct 31, 2006 12:16 am

#107572 - simonjhall - Tue Oct 31, 2006 12:33 am

#107894 - silent_code - Thu Nov 02, 2006 10:54 pm

#108227 - simonjhall - Mon Nov 06, 2006 9:58 pm

#108238 - xtoc - Mon Nov 06, 2006 10:51 pm

#108358 - simonjhall - Wed Nov 08, 2006 12:13 am

#108363 - sajiimori - Wed Nov 08, 2006 1:05 am

#108364 - Lazy1 - Wed Nov 08, 2006 2:03 am

#108947 - Schtee - Mon Nov 13, 2006 12:06 pm

#108951 - simonjhall - Mon Nov 13, 2006 1:45 pm

#108954 - Lazy1 - Mon Nov 13, 2006 2:21 pm

#108963 - simonjhall - Mon Nov 13, 2006 4:50 pm

#108975 - OOPMan - Mon Nov 13, 2006 6:31 pm

#108976 - Devil_Spawn - Mon Nov 13, 2006 6:42 pm

#109005 - simonjhall - Mon Nov 13, 2006 11:45 pm

#109032 - OOPMan - Tue Nov 14, 2006 7:31 am

#109063 - josath - Tue Nov 14, 2006 6:06 pm

#110050 - simonjhall - Fri Nov 24, 2006 11:00 pm

#110083 - OOPMan - Sat Nov 25, 2006 8:50 am

#110109 - simonjhall - Sat Nov 25, 2006 5:22 pm

#110110 - PeterM - Sat Nov 25, 2006 5:35 pm

#110119 - HyperHacker - Sat Nov 25, 2006 7:33 pm

#110125 - simonjhall - Sat Nov 25, 2006 8:05 pm

#110129 - HyperHacker - Sat Nov 25, 2006 8:23 pm

#110131 - tepples - Sat Nov 25, 2006 8:30 pm

#110132 - PeterM - Sat Nov 25, 2006 8:31 pm

#110135 - Lazy1 - Sat Nov 25, 2006 8:42 pm

#110138 - bear - Sat Nov 25, 2006 9:45 pm

#110152 - Dood77 - Sun Nov 26, 2006 1:43 am

#110158 - simonjhall - Sun Nov 26, 2006 2:28 am

#110159 - Lick - Sun Nov 26, 2006 2:36 am

#110162 - simonjhall - Sun Nov 26, 2006 3:00 am

#110163 - Lazy1 - Sun Nov 26, 2006 3:24 am

#110171 - PeterM - Sun Nov 26, 2006 9:59 am

#110178 - bear - Sun Nov 26, 2006 1:31 pm

#110204 - shadowghost21 - Sun Nov 26, 2006 7:31 pm

#110247 - f3 - Mon Nov 27, 2006 7:02 am

#110323 - simonjhall - Mon Nov 27, 2006 9:46 pm

#110324 - simonjhall - Mon Nov 27, 2006 9:53 pm

#110342 - PeterM - Mon Nov 27, 2006 11:36 pm

#110345 - simonjhall - Tue Nov 28, 2006 12:11 am

#110365 - Dood77 - Tue Nov 28, 2006 2:22 am

#110398 - OOPMan - Tue Nov 28, 2006 8:25 am

#110430 - Lazy1 - Tue Nov 28, 2006 4:11 pm

#110434 - OOPMan - Tue Nov 28, 2006 5:03 pm

#110442 - josath - Tue Nov 28, 2006 5:50 pm

#110450 - Sausage Boy - Tue Nov 28, 2006 6:15 pm

#110456 - Lazy1 - Tue Nov 28, 2006 7:05 pm

#110494 - OOPMan - Tue Nov 28, 2006 10:22 pm

#110507 - Lazy1 - Tue Nov 28, 2006 11:03 pm

#110515 - chishm - Tue Nov 28, 2006 11:52 pm

#110730 - simonjhall - Fri Dec 01, 2006 1:02 am

#110732 - PeterM - Fri Dec 01, 2006 1:07 am

#110738 - josath - Fri Dec 01, 2006 2:27 am

#110768 - simonjhall - Fri Dec 01, 2006 10:55 am

#110769 - Schtee - Fri Dec 01, 2006 11:33 am

#110848 - simonjhall - Sat Dec 02, 2006 6:05 am

#110857 - Mrshlee - Sat Dec 02, 2006 7:29 am

#110862 - PeterM - Sat Dec 02, 2006 8:43 am

#110867 - Sunray - Sat Dec 02, 2006 10:56 am

#110909 - simonjhall - Sat Dec 02, 2006 7:56 pm

#110913 - Lazy1 - Sat Dec 02, 2006 8:26 pm

#110926 - f3 - Sat Dec 02, 2006 10:52 pm

#110982 - xtoc - Sun Dec 03, 2006 11:24 am

#110994 - simonjhall - Sun Dec 03, 2006 1:45 pm

#110996 - Sektor - Sun Dec 03, 2006 1:55 pm

#111008 - xtoc - Sun Dec 03, 2006 3:33 pm

#111022 - shadowghost21 - Sun Dec 03, 2006 6:56 pm

#111033 - OOPMan - Sun Dec 03, 2006 7:51 pm