ProQuake 4.70 PSP Build

[leileilol]

Why not just use DXT1 compression then? At least don't have to manage an individual palette for that... unless PSP can't compress textures on-load per the S3TC standard. (See: Quake3, where r_ext_compressed_textures 1 just dxt1's everything where your card is supported)

[Downsider]

You can do that; my engine loads all 8-bit textures into DXT1 compressed textures, but the downside is the compression artifacts that do occur compared to a regular paletted texture. Then again, they're not really noticeable and totally worth being able to store twice as many textures.

EDIT:

To elaborate, the PSP supports DXT1, DXT3, and DXT5 compression.

[mh]

DXT formats can degrade Quake's low-res images something horrid. I used them in DirectQ for a long time and eventually dumped them as the quality loss - especially on menu and HUD graphics - was unacceptable.

The basic problem is that they reduce blocks of 4x4 texels to a 4-colour 16bpp palletised format. If there's wide variety between the texels in each block then the reduction will give bad results. And of course with low-res graphics this is more likely to happen. They're a lot like JPEGs in many respects, so they really only work well with high-res textures where there are smooth colour transitions.

DXT1 only supports 1-bit alpha so it's not really suitable for all textures. DXT3 or DXT5 are required there.

Compressed formats also take much longer to load, unless you're storing them pre-compressed on-disk.

On the other hand they do take less texture memory and also give a nice performance boost so you'll need to evaluate them for yourself and decide if the trade-off is worth it.

PCX for textures will do absolutely nothing to reduce texture memory usage by the way. It's all down to the internal format parameter, and the OpenGL spec clearly states that this is going to be a 4-component format (with the missing components filled in for you) irrespective of what you specify there.

[leileilol]

PCX for textures will do absolutely nothing to reduce texture memory usage by the way. It's all down to the internal format parameter, and the OpenGL spec clearly states that this is going to be a 4-component format (with the missing components filled in for you) irrespective of what you specify there.

Unless you had a 3dfx card and did stuff for the 3dfx minigl driver. By the way don't forget this is a PSP thread where paletted textures also benefit and OpenGL specs is near almost irrelevant.

[Downsider]

PCX for textures will do absolutely nothing to reduce texture memory usage by the way. It's all down to the internal format parameter, and the OpenGL spec clearly states that this is going to be a 4-component format (with the missing components filled in for you) irrespective of what you specify there.

PSP's GU API =/= OpenGL

The PSP's GPU supports CLUTs and 8-bit textures.

[Mexicouger]

Still looking forward to this engine. This one seems more clean and adaptable. Chances are, I can adapt this engine easier than Crow_Bars

[avirox]

Damn, wish we had this engine when I was working on Solitude. Good work, Baker!

[Baker]

I'm hoping I get this version out Friday and, if so, you should be able to use the Code::Blocks IDE to build it for the PSP [and in my mind, more importantly use the Code::Blocks IDE to quickly fix compile errors].



Crosses fingers that nothing weird gets into the way. Keep in mind, my engine versions aren't just PSP so I've got to make sure the stuff works on, say, Windows and OS X and I am trying to bust out an SDL Linux version too.

At the moment, I'm trying to get the entire project more properly organized for convenience like in my mind how DarkPlaces is. On desktop operating systems, I want the source to be able to be unzipped as a subfolder in the Quake folder and to compile the binary to the Quake folder and the importance --- in my mind --- of Code::Blocks is that it is a quick download (unlike Visual Studio behemoths) so the source can ported around on a USB Flash drive and compiled almost at-will on any machine you happen to be at.

[Jukki]

this sounds cool. (and if i realy undestand with my english i am able to work this on schools comp soon too )

[Mexicouger]

Code:Blocks isn't the only thing you can compile with right? You should be able to compile with Cygwin?

I really don't want to have to get another compiler -_-

[frag.machine]

Code::Blocks is essencially an IDE. You can choose an already installed compiler to work with, including MSVS and cigwin.

Baker: nice to hear about your choice to Code::Blocks.

[Baker]

Code:Blocks isn't the only thing you can compile with right? You should be able to compile with Cygwin?

I really don't want to have to get another compiler -_-

Like Frag Machine said, Code::Blocks isn't a compiler it is just an IDE. I'm not making use of Code::Blocks the only way to compile it or anything, you can still do it the "old way".

Baker: nice to hear about your choice to Code::Blocks.

Ironically, the PSP engine got me hooked on the gcc compiler. And I could work on the PSP engine anywhere and compile. It made me annoyed that I couldn't do the same with my Windows version because of super-bloated Visual Studio.

I took a look at qbism's Code::Blocks project file and decided to make one for ProQuake and built a Code::Blocks and g++ ProQuake project.
Which caused me to take another look at Ubuntu Linux since Code::Blocks works there too ... And, of course, the FlashQuake build of ProQuake uses Cygwin ... so obviously I'm trying to get all this stuff optimally organized.

But Code::Blocks is really the kind of true IDE solution that has long been needed. I'll continue to have a Visual Studio project file, but I view accessibility to truly free and easy to install/download as a core component to engine development accessibility and the Code::Blocks + MinGW download is the only thing required to compile an OpenGL Quake engine on Windows and it is just a quick install 75 MB download.

Visual Studio is damn near 1 GB and requires this and that and then a lot of messing around plus modern versions are sluggish and make big fat engine .exe files far larger than prior versions for no obvious reason.

Did I mention I'm happy to see high quality open source development tools? (/End redundancy joke)

Yeah ... I like Code::Blocks. Not quite as much as Visual Studio, but it is so close. The freeness, portability, ease of installation and multiplatform support more than makes up for 1 or 2 tiny things I think Visual Studio IDE does a bit better.

[Jukki]

Nice to hear. Me cant wait XD

[betasword]

This engine sounds fantastic so far, especially having been referred to this be MDave himself. I'm not going to try the version up on the first page yet, as from the sounds of it the new version should be out sometime in the near future. But I do have a question regarding the external texture support. I know you said the engine won't load alpha channels out of .pcx images, but is there some way it can at least do on-or-off transparency? I guess that'd be 1-bit transparency or something like that. Still, having something like that at the very least would be absolutely awesome, as I have several textures that make use of that (grates and such).

Other than that, I look forward to giving the next version a test once it's available!

[Baker]

This engine sounds fantastic so far, especially having been referred to this be MDave himself. I'm not going to try the version up on the first page yet, as from the sounds of it the new version should be out sometime in the near future. But I do have a question regarding the external texture support. I know you said the engine won't load alpha channels out of .pcx images, but is there some way it can at least do on-or-off transparency? I guess that'd be 1-bit transparency or something like that. Still, having something like that at the very least would be absolutely awesome, as I have several textures that make use of that (grates and such).

Other than that, I look forward to giving the next version a test once it's available!

Fence textures are important to me. The version I am trying to get out won't support that (and although I like fence textures, I'm not sure where that is on my list of priorities). At the moment, the main thing that holding up the release more relates to getting to whole sum of the source structure organized. So the status of the getting this version out is day-to-day, but it won't be today or tomorrow (won't have the time) so I'm thinking Thursday is most likely.

I'm glad you and a few others are looking forward to the release. And I do need testing and people playing around with it for suggestions and possibly bug reports.

Thanks!