GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[oldyz]

Ollllo here:

i was wondering if a version of Perfect Dark could be hacked to
allow it to fully function without the use of the Expansion pack -

this version would suffer in the texture quality department, of course, hell, the overall textures would even turn out to be inferior to Goldeneye's quality - not to mention that if it is achieved, there is no doubt that there would be frame-rate issues in coop BUT

Would there be Any noticeable benefits on the performance of the game, WHEN the expansion pack is present after such Rom optimization is implemented -?

As for other benefits, it would probably help to resolve some issues that seem to pop up when custom levels are created -

1 -when it comes to multiplayer:
Oldyz & I have had the nagging suspicion that Rareware's decision to make the combat simulator JUMPER PACK compatible is the culprit, the main cause that PD's multiplayer levels are so different in quality in comparison to Goldeneye's -
also the reason we see no single player sections of levels in combat sim.

This also probably indicates that there is limitations to the levels that you can create in multiplayer -
and texture rich environments are pretty much not possible -

Let's remember - goldeneye's complex levels based on single player sections work , because they are linked to their single player counterparts-
and with some gameshark trickery or editing, they can be forced to work as full zones with not many frame-rate problems (crashes yes)


2 - for single player:
a Jumper pack compatible approach might help the creation of complex levels , ensuring that the levels run well & then even better with expansion
any texture quality issues are not really a problem, since emulation can compensate for this via texture packs - the future of GE & PD gaming lies inevitably in emulation anyways.

So finally i think either one has to be done:
Force Multiplayer mode to have a higher threshold of limitations, making it take advantage of the expansion pack -
(than means a EXPANSION PACK required version of PD)
OR
Lower the overall game quality to JUMPER PACK compatibility - for an overall better framerate in all modes.

Oldyz is sardined on bus 45

Last edited by oldyz on Sat Feb 11, 2012 12:16 pm; edited 1 time in total

[00Dark]

A Jumper Pak quality PD wouldn't be worth playing if the graphics and textures are worse than GoldenEye. However, I imagine that someone (not me) could make more things available in the game without the Expansion Pak like the full multiplayer component of Perfect Dark. Probably not any solo or co-op/counter-op stuff though. Get on eBay and buy a Nintendo 64 Expansion Pak for dirt cheap from some eBay store. You probably can get one for a penny because one time I won a bid auction and got a brand new Perfect Dark cartridge in the box factory sealed! It was pretty cool.

Anyways, thanks for sending me a private message about the multiplayer levels. I'll see what I can do about requests. All of the levels I've made are designed not to conflict with the solo missions just by keeping all the retail pads in the pads file and just adding new ones for the multiplayer setup. That's because the solo missions setup needs to have all of it's usual pads for the level to even work.

The setup and pads files are injected using 39850 Modifications. The multiplayer setup files for solo mission levels are always empty and always separately injected. I should make a YouTube tutorial on how I make my Perfect Dark levels so that everyone else can too!

Peace bro,
00Dark

[oldyz]

hello guys -

First to 00dark -
i had olllo write you because i could not find correct words to tell you what i was thinking months ago, so i never told you about the objects - i did write it around the forum , but it is not very clear -

about the ugly version of perfect dark -
the ugly version is a thing that is supposed to make the game work better in the emulators - it has no intention for working in the console -

Now for Wreck (cradle), Sogun (kakariko), & 00action (jungle)

yesterday i realized that textures can be made very small & ugly -
so ugly that you don't want to play them in the console -
But in the computer - texture packs take care of restoring them to what they are originally -

if any of you can, try this example for cradle:
load the level in the emulator - dump the textures for a high resolution pack -
using the editor:
make the textures a quarter of the size - (remember that texture packs restore them to 4 times the size)
make them black & white 8 bits 4 bits - anything - just keep the same number of textures.
test the level to see how it runs with the super ugly textures -
it should run faster -
now apply the texture pack and everything will look normal and have the benefit of running faster-

Benefit # 1 if this works you can release the patches with texture packs and people can enjoy the levels for multiplayer for the computers

if you don't have time send me the problem level & i want to see if this works .

EN ESPAÑOL

para 00dark -
No te escribi por que en ingles no podia explicar bien mi teoria de los objetos, asi que le encargue a olllo para que te dijera.
Sobre las Texturas horribles - la version horrible de perfec dark es algo que se me ocurrio para que el juego funcione de mejor manera en las PC - por desgracia no es para que se use en la consola-

Para Wreck (cradle), Sogun (kakariko), & 00action (jungle)
quiero que probemos esto:
usando el emulador - carguen sus niveles problematicos y hagan un dump de texturas (de preferecia con los dos plugins glide y -- el otro, para mallor seguridad)
ya que tengan sus packetes de texturas -
Editen su nivel con el Goldeneye editor:
1- reduzcan el tamaño de las texturas a un 25 % - recuerden que el texture pack las hace 4 veces mas grandes
2 - reduscan los colores de las texturas, haganlas de 8 4 o hasta 2 bits si es posible, blanco total o minimo blanco y negro como calidad de fotocopia, eso si mantengan el numero de texturas igual.

en el emulador carguen el ROM y chequen - el nivel debe de funcionar de forma mas fluida - FEO pero fluido -
ahora usando su plugin favorito carguen el texture pack -
Todo debe de correr mejor y con el aspecto de antes -

El beneficio #1 de esta tecnica, si funciona, es que pueden ahora sacar los parches junto con su texture pack, y los fans de Perfect pueden disfrutar de estos niveles en las PC

Si no tienen tiempo de probar este metodo, mandenme el archivo para ver si yo puedo (quiero ver personalmente si funciona)

[Sogun]

Hi oldyz.

That's a great idea to improve performance in PD Kakariko. I'm going to try it as a separate project, as I still think that something can be done with the level to match its smoothness with the one in GE.
The levels will end having the same N64ish look, and loading a few small textures before running the rom shouldn't take more than a few seconds. (I remember using custom textures for Ocarina of Time and the waiting was long)

As I said, it's a good idea but it can backfire to the user. Personally, having one rom for each custom level is kind of anoying because of two reasons:
-you have to change the rom in order to play another level.
-those roms consume space in your HDD. It's ok with GE 12 MB, but not that ok with PD 32 MB.

Making a texture patch for every new custom level may not be as easy as it seems. I think you need to store those textures inside a folder that can only have an specific name (for the emulator to know what game uses those textures) and has to be in an specific directory. If textures from two different custom levels share the same ID (I don't know if this could happen but it seems likely), you'll have a problem. The only way I can think to solve it is having multiple emulators in different folders containing a certain texture pack. But doing this will increase the level of anoyance by one:
-you'll need multiple emulators that consumes more space in HDD, and you'll have to open a new emulator to play another custom level.

Perhaps the method has changed but I remember it was something like that.

So I'll use your idea as a side route until we figured out what is happenging with PD Kakariko, but I'll try to don't make a habbit of it.


Un saludo.

[oldyz]

voy a tener que actualizar las instrucciones :

1 - usando el emulador - carguen sus niveles problematicos y hagan un dump de texturas (de preferecia con los dos plugins glide y Rice's, para mallor seguridad)
EN CASO de que las texturas del nivel "custom" no salgan de buena calidad , usen las originales del parche haciendo un dump con el editor,y cambiandoles el nombre para el "texture pack"

--------ya que tengan sus packetes de texturas como respaldo-

2- usando el Goldeneye Editor reduzcan el tamaño de las texturas a un 25 % - recuerden que el texture pack las hace 4 veces mas grandes
NOTA -al reducir el tamaño puede que el plugin con el texture pack haga que la textura de multiplique por 4
- como esto es muy probable que suceda, saltense este paso-
si quieren hacerlo de todos modos , pongan atencion: al cambiar el tamaño de las texturas, tambien el tamaño de los UV tienen que ser relativos O en dado caso los plugin puden modificar la presentacion de las texturas , pero.....

3 - despues reduscan los colores de las texturas, haganlas de 8 4 o hasta 2 bits si es posible, blanco total o minimo blanco y negro como calidad de fotocopia, eso si mantengan el numero de texturas igual.

4- apliquen el parche con texturas horribles y UVs modificados

5- Cambien el nombre interno del ROM parchado - usando el editor de preferencia
si el editor no tiene la funcion de cambiar el nombre, haganlo ya sea con esta herramienta:
http://www.romhacking.net/utilities/791/
o con - http://www.zophar.net/utilities/hexutil/translhextion.html
esto permite que el paquete de texuras no haga conflicto con el de Perfect Dark.
ADVERTENCIA - el primer programa me dio advertencia de virus - yo no lo use -
El segundo programa me dijo que escribio algo en el registro

Usando Translhextion16c:
abran el rom parchado


cambien el nombre letra por letra , no copiar y pegar


asi se ve el rom en el emulador - los saves, states y carpetas de dump coincidirán


por favor avisenme si en efecto estos programas pueden ser nocivos, aqui en este tema: http://www.shootersforever.com/forums_message_boards/viewtopic.php?p=49299#49299

6 - en el emulador carguen el ROM y chequen - el nivel debe de funcionar de forma mas fluida - FEO pero fluido -

7- cambien el nobre de la carpeta del Texture pack del dump del paso 1, al nombre interno del ROM parchado

8- ahora usando su plugin favorito carguen el texture pack -
Todo debe de correr mejor y con el aspecto de antes -
------------------------------------------------------------------------------
English
I'll have to update the instructions:

1 - using the emulator - load problematic levels and make a dump textures (preferecia with both glide and Rice's plugins for best security)
IF that "custom" level textures don't have good quality, using the original patch make a dump with the editor, and changing the texture names to match the "texture pack"names

-------- the texture pack will serve as a backup-

2 - using the Goldeneye Editor, reduce the size of the textures to 25% - remember that the texture pack makes 4 times larger
NOTE: reducing the size might result in the texture showing 4 times in the surfaces when the texture pack is activated-
since it is very likely to happen skip this step -
If you decide to still reduce the size of the textures, their UV also has to have a relative update OR the plugins can be configured to modify this but....

3 - after reduce the colors of the textures, make them of 8 4 or even 2 bits if possible, or minimum total white, or black and white photocopy quality, the number of textures DO have to remain the same.

4 - apply the patch with horrible textures & relative UVs

5 - Change the internal name of the ROM patch Using the Editor
if the Goldeneye editor cannot change the internal name use:
either with this tool:
http://www.romhacking.net/utilities/791/
or - http://www.zophar.net/utilities/hexutil/translhextion.html
This allows the package texuras do not conflict with Perfect Dark.
WARNING - the first program gave me virus warning - I did not use -
The second program told me that it wrote something in the registry

Using Translhextion16c:
open the rom patched


change the name letter by letter, NOT copy and paste


so you see the rom in the emulator - the saves, states and folders match dump folder


please let me know if these programs can actually be harmful, here in this thread:http://www.shootersforever.com/forums_message_boards/viewtopic.php?p=49299#49299

6 - in the loaded emulator and the ROM check - the level should work in a more fluid way- UGLY but fluid -

7 - change the folder name of Texture pack from step 1, to the internal name of the patched ROM

8 - Now using your favorite plugin load the texture pack -
Everything should run better and look like before -

Last edited by oldyz on Mon Feb 13, 2012 2:58 pm; edited 2 times in total

[zoinkity]

I don't think you quite understand how graphics are stored on hardware. Images first, since it is a little easier to explain.

All color images in virtually any N64 game will be an indexed image with either a 16 or 256 color palette. Now, PD almost exclusively uses 16 color palettes, mostly because a cleaner look tends to look better in general. The size of the image would be calculated like this:
1/2 (w * h) + 32
Concidering the only difference between the smallest variety of greyscale image and this would be the palette, that's pretty darn small. You can't make room based on that.

You can reduce the size of the image itself (scale it down, for instance), but this will require you to change every model that uses that image. This isn't too much trouble with, say, a character, since the only images that roll-over would be hands, shoes, etc. Wall textures though...
The reason for this is UV positions are not relative or a percentage like in PC games. Prebuilt display lists, which is what almost every N64 game uses, compute the UV and store it ahead of time. This value is roughly 32 times greater than the actual pixel width or height of the image. So, if you shrunk an image by half and didn't update the UV, that texture would repeat twice over the same distance.

Another route exploits the fact that PD uses a larger number of images per model compared to GE. An arm will be made of 3-4 images on average. Again, by modifying the original model to remap textures you could get away with fewer textures in general.

The third method, and most likely to permit more content on a 4MB system, is to replace all the models in the game with lower polycount models. When I say all I mean all; the biggest culprit are the stages themselves.
Unlike GE, PD does not load rooms based on visibility. It only draws visible rooms. PD loads and expands all of a stages' rooms into memory at the start of the stage. This removes the overhead of determining if a room is visible, allocating memory for the room and its textures, decompressing and formatting the room and its textures, and then drawing it.
The more complicated the stage's telemetry, the more rooms and display lists are involved. Unless the entire stage can fit within memory in addition to the models, textures, and player data needed to run it you simply can't load that stage.
Keep in mind there are stages that can be loaded that aren't available in 4MB mode. Krijy made a list of them in his documentation.

The actual solution is a bit annoying. If you were to code a room-loading mechanism you'd be able to play most of PD in 4MB mode, albeit with a bit more memory bottleneck. If you were to reduce every model's polycount you'd be able to get more things to load at once given the constraints. Or, if you were to tamper with most objects and characters you'd also be able to free up a small amount of memory.
Either way, it really is a pain.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[oldyz]

Ollllo here -

zoinkity wrote:

.......So, if you shrunk an image by half and didn't update the UV, that texture would repeat twice over the same distance....

ohhh crud - i feared that would happen --


Well - here is the point as i understand it from what Oldyz wants to see happen-

he would like to have a texture -less
Sound- less Perfect Dark ROM -
with a collection of dummy sounds & dummy textures that enable the
plugins for emulators to replace this data via Packs (sound packs & texture packs)
If this dummy files can be reduced to zero, but allow the emulator to load the packs in the same way they do when the texture files in the ROM are normal,it would be even better.

this to allow the virtual N64 to pretty much just take care of the polygons,
the midi & the rest -
& the computers to take care of the textures & sounds -

How much would the performance of the game improve with simple tiny size sounds & textures?
i think there is no way to really know unless it is tryed

I'm hoping that in the worst cases enough to make some problem levels playable or at least remove the lag on problem areas.

thanks Zoinkity


PS - updated the Instructions of horror with the UV issue -
emulator plugins can modify how textures show ,but i'm not sure that if a texture pack texture shows 4 times because of an unmodified UV, a plugin adjustment ignores this and reduces this effect by half -
i'll have to test this and if it is true, hackers would not have to update the UV data, USERS have to adjust how the texture packs are displayed

Oldyz is bringing home Mariscos o Calzones - either way i'll probably regret it