22-06-06, 09:34 | #11 | |
Member
Joined: Dec 2005
Posts: 491
|
Actually, TREP can fix this bug!
Quote:
I am sorry i haven't noticed that this option also removes stretching bug. Looks like it is right that it caused by overloading level buffer. Last edited by Pyuaumch; 22-06-06 at 12:45. |
|
22-06-06, 16:09 | #12 |
Member
Joined: Dec 2005
Posts: 851
|
Elen, to avoid sacrifices: what about splitting you level?
|
22-06-06, 17:00 | #13 |
Member
Joined: Jul 2005
Posts: 17,433
|
*Sorry for being slightly off-topic*
I don't mean to sound daft, but didn't a similar thing happen in AoD (PC version at least)? I distinctly remember Kurtis' hair hanging down around his ankles when he and Lara meet in the bio lab - not to mention Eckhardt's coat having a mind of its own during cutscenes Lara would also "break up" in certain areas; her leg would suddenly stretch and distort, or her jacket would fly about for no reason. I'm just curious if this problem in LE is related somehow in terms of WADs and overloading the textures. Again, bit of a random post but it just crossed my mind...... |
22-06-06, 17:14 | #14 |
Member
Joined: Mar 2005
Posts: 2,378
|
This happens when the level gets too big. Just adding your flyby was the drop to overload your level. To get rid of this bug is to lower your texture pages in strpix as texture memory has a big influence on this.
I read that you deleted these objects already but if you want to keep them you can retexture them with existing textures from other objects. Save the wad and all textures not used will be deleted. Your bug might be gone but I'm sure you are on the edge. There is a golden rule. The lower the texture pages are from the wad the bigger you can make the level. |
22-06-06, 17:47 | #15 |
Member
Joined: Dec 2005
Posts: 491
|
Pff...
What do you mean "level gets too big"? Since i've begun to read TRLE forums, i'm seeing these evasive phrases all over - "level gets too big", "you're close to the limits", "you've used too much stuff", "your level is too complex", "try to cut something off". Well, can someone tell, what exactly this ghostly limit you're talking about? Look, there is common buffer in TR4 engine which size by default is 5000000 bytes. This buffer then divided into smaller parts used for various data - for items, enemies, etc. Maybe you're talking about this buffer? And please, Elen, if you have back-up of your old uncut project, test it with TREP's object increaser option. This option will increase common level buffer mentioned above (from 5000000 bytes to 20000000 bytes). As i said, it MAY fix stretching polygons bug. |
22-06-06, 19:59 | #16 | |||
Golden
Joined: May 2002
Posts: 28,871
|
Thank you everyone for the replies. I personally don't understand the numbers I get when I convert the TOM file and what they mean, but I do understand that you can't place zillion objects; there is always a limit. I saw the difference when I removed some objects from my project and WAD.
Quote:
Quote:
Quote:
Again, thanks everyone for the replies |
|||
22-06-06, 20:09 | #17 |
Member
Joined: Dec 2005
Posts: 491
|
|
22-06-06, 20:33 | #18 | |
Member
Joined: Mar 2005
Posts: 2,378
|
Quote:
If I delete textures from a wad then I can add more rooms. I had to bring down a wad in textures from 9 to 7 pages to get my cathedral working of 172 rooms. They were tiny rooms connected to one big area to create stacked rooms with vertical portals to create arches with textures. If I increased my wad with textures the level crashed. This is with tracking of the alloc file buffer that is a main aspect in level design for us to work with. While I have levels with an alloc file buffer of 720.000 my cathedral would crash already at 640.000. So this way I learned the combination of wad size through level size. I knew I was on the brink when the problem appeared that Elen has now. In the beginning I worked too precise with selecting too many partial textures. This way my first level would not run on some PC's from that time. I had more then 300 texture info. I reduced this to 280 or so in the final version and info returned while converting. Now I'm sure it will run on any PC now. So now I yell at everybody that texture memory is the key to prevent level crash or size of levels. And as it turns out I'm right. Now I'm sure you know more about it then me but you can speak in the techincal language |
|
22-06-06, 20:59 | #19 |
Golden
Joined: May 2002
Posts: 28,871
|
I think I understand what Piega means and it seems logical to me. Anyway, I'm downloading this tool and I'll give it a try. Ta ta!!!
btw\ if I use TREP, my level will run with the standard tomb4.exe file, won't it? *edit: I just took a look at the readme file and I saw that you can't use the standard exe. I now understand what this tool makes, but I can't use it for this level. I'll stick to Piega's solution for now, and I'll use this brilliant tool for my next level. |
22-06-06, 21:05 | #20 |
Member
Joined: Dec 2005
Posts: 491
|
I don't think that exactly texture memory causes various bugs and crashes. The fact is TR4 dynamically allocates memory for textures and it has no deal with static 5MB level buffer (of course Our Dearest Core Design Programmers have been not so wiseful sometimes, but they're not THAT stupid to allocate static memory region for textures). You can use as much textures as you want - the only limit is your overall RAM and system requirements you want to hold. Maximum i have tested is 24 megabytes texture set (i. e. 128 room texture pages) and it worked fine (no any crashes).
Most likely, various engine bugs (and stretching polys bug too) can be caused by overloading texture infos, not texture memory. Texture infos and textures loaded and kept seperately by TR4 engine. And indeed, Texture Infos are loaded into this stupid static 5MB level buffer (unlike textures themselves, which is loaded into dynamically allocated seperate memory region). When you have too much Texture Infos and there is also lot of other data which is loaded into static level buffer (for example, lots of rooms), overflow can happen and bugs will appear. When you increasing level buffer from 5 to 20 MB (with TREP Increase enemy / object limits option, chance to get static level buffer overflow is much lower than with default 5 MB buffer. So test your old binned levels with too much rooms/textures/objects in it - maybe it will work fine now . @ELEN: Uhm... He-he... Not really . TREP modifies TR4 engine itself, so modified executable file is needed to play your level correctly. However, if you have done only cosmetical changes (for example, flare colours, inventory constants etc.), it CAN be played with default exe. But if you have used patched-exe-only features in your level, like meshes with more than 255 vertices, sounds larger than 256 kbytes etc., then your level won't play with default exe. But of course you can include modified executable in your level package (there is already a couple of levels with bundled custom tomb4.exe), so player can use it instead default executable. Last edited by Pyuaumch; 22-06-06 at 21:10. |
Thread Tools | |
|
|