Resolution in Q-gears

  • Thread starter Thread starter halkun
  • Start date Start date
Status
Not open for further replies.
ack!  Remember, buffers are FASTER than video mem surfaces when you're doing hard-coded per-pixel ops.

And just remember, you can SAI yourself silly but maybe you should have an optional grain filter.  This will "add" detail that simply doesn't exist in a stretched image.  I've especially tried grain (randomly affect LIGHTNESS only--that is, affect r,g,and b by the random value randomized each PIXEL) on stretched images that are even blurry and not using SAI (for photo editing work), and it makes stuff look good stretched.  For speed, you could apply any stretching or filters ONCE on LOADING the image if you're using a buffer anyway.  This will obviously speed up performance immensely.  However, it would look MORE REALISTIC if noise was applied every FRAME (slow, maybe have that as an option though).  Now don't distract yourself from coding the core just yet ;), but Another optional filter to add to the engine sometime should be an NTSC color filter (to make it look like it was really supposed to look on the TV, for which the textures and backgrounds were all designed).  Sorry for giving you too many ideas lol.
-ProtoArmor
http://www.expertmultimedia.com/protoarmor (go there and click contact for the contact form)
 
And just remember, you can SAI yourself silly but maybe you should have an optional grain filter.
Click to expand...
Very much agreed on this. I've never seen grain used in emulators, but I've used it in photoshop to hide either too severe jpeg-compression, or the artifacts from too large resizes. And of course last but not least; I use very small amounts of grain on ffdshow to hide compression artifacts on badly mastered DVDs. All that it does really well, I think that it would be worth a shot to try it.

It can't and won't add any real detail (one that would carry actual information with it), but it is much more pleasing to the eye than the alternative.

Not sure, but I suppose that ffdshow source might have a rather fast grain-filter in it, after all it is meant to be run on live video, up to very high resolutions.
 
First we need an Officially accepted translation process from ABGR 16 format to R8G8B8A8 or whatever texture format we plan on using.
Click to expand...
R4G4B4A4, It's faster :D
 
So what do they look like with HQ3X and HQ4X?
Click to expand...
My guess is not much different than HQ2x? :D
Anyway, for the ABGR, I made a table for the B, G, and R part:
https://www.ff7catalog.com/posts/50107/
Click to expand...
Yes I'm  sure most people are aware of that, however 'the official' accepted translation really implied that we need to spend time to be certain when a color is converted it's to the proper R8G8B8A8 numbers.  I know I have 2 conversion versions, they both work similiarly to what your table version does.  The primary difference is they examine the alpha channel. Fortunately FF7 uses it as a transparency bit and super black. (It's a strange artifact of the PS1) these do require consideration for alpha channel changing 0 00 00 00 is a clear color whereas 1 00 00 00 is black.  However  0 00 3F 00 is green (non transparent).  Fortunately 0 is the only exception so that makes things a bit easier.  The proper translation is needed for all color handling in FF7 except the menu background colors.  They used to guruad rectangle primitive for that and it accepts 4 B8G8R8 colors as part of the GPU opcode. :)
What if someone made a preprocessor or something to do this before we run the program?
Click to expand...
No that would be altering the original content, which is of course something that the project wishes to avoid.  Even if just before the program runs it's still creating content from copyrighted content. Then there is the fact you have several hundred battle scenes, field scenes, and battle models to go through.  Decompress process fold spindle and otherwise mutilate. That would from a few minutes to .. quite a few minutes  (LOL). :D

choascontrol:
Ummm that would be true on older hardware now it makes no difference.  With 32 bit machines and 64 bit data path and a GPU that uses R8G8B8A8 internally it might actually be a little slower.

Cyb - silly mood
 
I would really like the resolution upped as cosmetically possable...

You are right. I'm losing sight of getting this to run as "stock" as possable. The filters can come later.

However higher resolution is going to be a very high-demand fuctionality to have. Keep that in mind while lying down the code....

As this is going to be running on Computers, and the PC version did also concede that higher resolution would be a change for the better, it's something to look into when the field files start getting loaded.
 
Last edited:
Hey, don't forget that while you're playing around with HQ2X and SAI filters, maybe do some of that magic on the 3d textures like emulators do...
 
This wil include options for Diffrent Resolutions, We won;t need a filter for the Models
 
One thing at a time.

Halkun:
Look at borde's project in the tech forum. (VincentVal and ProtoArmor I suggest doing so as well).

Upping the resolution is a long term goal, short term is get it working right.  Yes people will want it, I will want it too :D

Erstwhile I'll put some time too the ISO media reading tomorrow and saturday. 

For some reason I can't sleep lately it's totally messed my days up.. SIGH.

Cyb
 
Yeah, sorry for jumping topic.  To simplify the scaling in relation to the masked portions though, what you could do is put the whole image together, scale it,, then copy it, then overlay the copy using a smoothed mask (this way there are no artifacts around the edges of the parts you can walk behind)
 
Last edited:
What about scanlines just for now?
Click to expand...
It's pretty simple, the engine isn't more than just something that loads a few things and reads data at the moment.  In other words it does not work.  There is no now yet.  No rendering to be done either.  Right now it's just reading some of the data, and learning what data needs to be read to start up.  There is no engine yet, I repeat there is no engine yet.  Essentially what is going on is mental twitterpation until the engine can actually read the correct chunks of data and functionally start the game, which it cannot.  Then one can worry about graphics backgrounds textures etc. when this happens.  Rememb er it has to be able to RUN the script code in order for it to know what to do even.

Cyb
 
Yah I know, but you know how it is when you get twitterpated :roll:
Don't let starry-eyed fans distract you from programming the core.  I too am doing the invisible part of a game engine so...I know what it's like when everyone is so excited about your ideas, and meanwhile you have an unholy number of lines of script engine code to pull out of your hat.
 
Status
Not open for further replies.
Back
Top