Author |
Message |
2dragons Novice
Joined: Feb 17 2004 Posts: 95 Offline
|
Posted: Sun Aug 08, 2004 11:23 am Post subject: |
|
|
|
|
Aye i'm on dialup too it sux. One of my goals is remove the usage of the JAI to remove file size. Also if we move to webstart you'll only have to download upon updates although I'm not sure to what extent you'll have to 'redownload.' |
|
Back to top |
|
|
Mr Ekted Movie Geek
Gender: Joined: Feb 09 2004 Posts: 1379 Offline
|
Posted: Sun Aug 08, 2004 11:46 am Post subject: |
|
|
|
|
Webstart sucks. This app would be 10x faster and only about 100K if it was done in C. _________________ 4,691 irradiated haggis! |
|
Back to top |
|
|
Dr Brain Flip-flopping like a wind surfer
Age:38 Gender: Joined: Dec 01 2002 Posts: 3502 Location: Hyperspace Offline
|
Posted: Sun Aug 08, 2004 12:22 pm Post subject: |
|
|
|
|
And it would also be 1/10 of the way along. Java is great for RAD.
Though I do not agree with your speed figures. Java is slower, but not that much slower. It's mostly a memory hog, not a CPU hog. _________________ Hyperspace Owner
Smong> so long as 99% deaths feel lame it will always be hyperspace to me |
|
Back to top |
|
|
i88gerbils Oldbie Server Help
Gender: Joined: Dec 13 2002 Posts: 423 Location: OH Offline
|
Posted: Sun Aug 08, 2004 1:37 pm Post subject: |
|
|
|
|
Except this program seems to eat 100% CPU when zoomed out completely, and take ~30 mb for a 2-tile map. _________________ Oldbie Server Help |
|
Back to top |
|
|
CypherJF I gargle nitroglycerin
Gender: Joined: Aug 14 2003 Posts: 2582 Location: USA Offline
|
Posted: Sun Aug 08, 2004 3:10 pm Post subject: |
|
|
|
|
I'm thinking don't include the "include" and "src" folders; for "update" versions; just the jar (and classes) that it needs to run.. ? _________________ Performance is often the art of cheating carefully. - James Gosling |
|
Back to top |
|
|
2dragons Novice
Joined: Feb 17 2004 Posts: 95 Offline
|
Posted: Sun Aug 08, 2004 7:37 pm Post subject: |
|
|
|
|
While we're at it lets write it ground up in assembly and port it to every machine/Os.
Oh shit and we better test on a 386 with 4 megs of ram.
Seriously...
lol |
|
Back to top |
|
|
2dragons Novice
Joined: Feb 17 2004 Posts: 95 Offline
|
Posted: Sun Aug 08, 2004 7:44 pm Post subject: |
|
|
|
|
Oh totally off topic but i was messing around with the idea of seeing what java could do in terms of an SS client.
while viewing elim in TW in Full-Screen Exclusive Mode
constant 61fps 1280x1024x32
fluctuating 58-61 1600x1200x32
This is with animation of ships/map. I never tried lower cause I didn't care. oh btw that's on a GF2 GTS |
|
Back to top |
|
|
Grelminar Creator of Asss
Joined: Feb 26 2003 Posts: 378 Offline
|
Posted: Mon Aug 09, 2004 4:15 am Post subject: |
|
|
|
|
To get back on topic:
This recent activity in level file tools inspired me to design a new file format for region data in asss. It's backwards-compatible, very extensible, and the region data is implementation-neutral.
It's described here: http://sscx.net/asss/extended-lvl-format.txt . The document also describes a few features based on regions that will be built into asss.
Note that none of this is implemented in asss yet. I want to get some feedback on the design and file format before I put effort into implementation. So please, make comments here or send them to me. |
|
Back to top |
|
|
Bak ?ls -s 0 in
Age:25 Gender: Joined: Jun 11 2004 Posts: 1826 Location: USA Offline
|
Posted: Mon Aug 09, 2004 8:19 am Post subject: |
|
|
|
|
very interesting, but I wouldn't be surprized if programs used a constant offset to determain where the lvl data starts, as they make you include a complete 256 color colortable.
Perhaps after the tile data would be a better place for the extra data, but we'd really have to check all the common applications to see how they handle this. |
|
Back to top |
|
|
Mine GO BOOM Hunch Hunch What What
Age:40 Gender: Joined: Aug 01 2002 Posts: 3614 Location: Las Vegas Offline
|
Posted: Mon Aug 09, 2004 10:19 am Post subject: |
|
|
|
|
Since we are getting new handlers for level editors and the server, could we also define a new extension where all it is, is the LVL file compressed using zlib? Will make storage on the server a bit smaller. Since the server already prepares for sending maps to client, it being stored compressed already allows it to only have to memory-map the file and not deal with compressing it. As for a good extension name, someone else will think of something better than glvl, which is currently untaken at least.
As for the no-tileset, why handle it? If the client will ever expand to understand a new tileset format, that will be the best time to exand the tileset, so you can have unlimited number of tiles as people want. Thus keeping the backwards compatiblity of the tilesetless maps should be phased out.
In the mean time, if a map wants the metadata, the level editor is already required to have SS's default tileset in it, it will just throw that in the front instead of saving it without a tileset. |
|
Back to top |
|
|
Dr Brain Flip-flopping like a wind surfer
Age:38 Gender: Joined: Dec 01 2002 Posts: 3502 Location: Hyperspace Offline
|
|
Back to top |
|
|
Grelminar Creator of Asss
Joined: Feb 26 2003 Posts: 378 Offline
|
Posted: Tue Aug 10, 2004 12:53 am Post subject: |
|
|
|
|
Bak wrote: | very interesting, but I wouldn't be surprized if programs used a constant offset to determain where the lvl data starts, as they make you include a complete 256 color colortable.
Perhaps after the tile data would be a better place for the extra data, but we'd really have to check all the common applications to see how they handle this. |
after the tile data wouldn't work so well, because the tile data has no end marker or length stored. so programs would just keep reading this data as if it were tiles.
regarding compatibility, i have yet to actually make one of these files and test it with various programs. i certainly might have to revise things depending on the results of those tests. |
|
Back to top |
|
|
Grelminar Creator of Asss
Joined: Feb 26 2003 Posts: 378 Offline
|
Posted: Tue Aug 10, 2004 12:56 am Post subject: |
|
|
|
|
Mine GO BOOM wrote: | Since we are getting new handlers for level editors and the server, could we also define a new extension where all it is, is the LVL file compressed using zlib?
|
sure, i don't see why asss can't support pre-compressed lvls. of course, it will have to decompress them when loading them, so it wouldn't save any memory in the running program, just on disk. and disks are big, so i don't see much incentive.
Mine GO BOOM wrote: |
As for the no-tileset, why handle it?
|
um, as the document says, no-tileset extended lvls aren't backwards compatible (and i can't see any way to make them be). |
|
Back to top |
|
|
Bak ?ls -s 0 in
Age:25 Gender: Joined: Jun 11 2004 Posts: 1826 Location: USA Offline
|
Posted: Tue Aug 10, 2004 9:11 am Post subject: |
|
|
|
|
Grelminar wrote: |
after the tile data wouldn't work so well, because the tile data has no end marker or length stored. so programs would just keep reading this data as if it were tiles. |
So what? we'd get more than 1024x1024 tiles? |
|
Back to top |
|
|
Cyan~Fire I'll count you!
Age:36 Gender: Joined: Jul 14 2003 Posts: 4608 Location: A Dream Offline
|
Posted: Tue Aug 10, 2004 5:05 pm Post subject: |
|
|
|
|
On one of my servers, LVLs take up 2.9mb and LVZs take up 11.4mb. I don't think LVLs are really a problem. _________________ This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him. |
|
Back to top |
|
|
CypherJF I gargle nitroglycerin
Gender: Joined: Aug 14 2003 Posts: 2582 Location: USA Offline
|
Posted: Tue Aug 10, 2004 5:56 pm Post subject: |
|
|
|
|
Nah, LVL's in themselves aren't that huge of a problem size wise, unless they make a full map, with a ton of tiles. LVZ's get big because of WAV and the usage of BMP's still. |
|
Back to top |
|
|
Mine GO BOOM Hunch Hunch What What
Age:40 Gender: Joined: Aug 01 2002 Posts: 3614 Location: Las Vegas Offline
|
Posted: Tue Aug 10, 2004 10:33 pm Post subject: |
|
|
|
|
CypherJF wrote: | the usage of BMP's still |
LVZ files by default are compressed using zlib, which does a pretty good job on bmp files. Try it sometime. Compress a bmp into an lvz, and then make one using png format. Shouldn't be off by too much. Or use my debuildlevel program to see compress stats on each file.
Yes, wave formats do take up a huge chunk. |
|
Back to top |
|
|
CypherJF I gargle nitroglycerin
Gender: Joined: Aug 14 2003 Posts: 2582 Location: USA Offline
|
Posted: Wed Aug 11, 2004 1:34 am Post subject: |
|
|
|
|
.shrug.
I just don't think there is a *need* for BMP anymore, is there?... :/ |
|
Back to top |
|
|
Mr Ekted Movie Geek
Gender: Joined: Feb 09 2004 Posts: 1379 Offline
|
Posted: Wed Aug 11, 2004 2:01 am Post subject: |
|
|
|
|
All images are converted to raw bitmaps when they are loaded into memory/video, even under non-Windows OS's. |
|
Back to top |
|
|
CypherJF I gargle nitroglycerin
Gender: Joined: Aug 14 2003 Posts: 2582 Location: USA Offline
|
Posted: Wed Aug 11, 2004 4:24 am Post subject: |
|
|
|
|
true true |
|
Back to top |
|
|
Mr Ekted Movie Geek
Gender: Joined: Feb 09 2004 Posts: 1379 Offline
|
Posted: Wed Aug 11, 2004 10:33 am Post subject: |
|
|
|
|
Actually, this is not always the case. Infantry doesn't do this. It stores images into a set of block instructions for drawing, and pseudo-executes them into system "display" memory during render. But this is a rare exception. |
|
Back to top |
|
|
Smong Server Help Squatter
Joined: 1043048991 Posts: 0x91E Offline
|
Posted: Thu Aug 12, 2004 4:58 pm Post subject: |
|
|
|
|
i88gerbils wrote: | PID %MEM VIRT SWAP RES CODE DATA SHR nFLT nDRT S PR NI %CPU COMMAND
29891 6.6 34020 0 33m 28 33m 12m 2945 5444 S 9 0 0.0 java | 6.6% mem? What is that in mb? Does ps include swap too? (I can't even remember how big I made my swap partition :/)
I think my chat client takes like 25mb of ram, and recently it has crashed the xserver a few times when loading up.
i88gerbils wrote: | Though, SWET only uses < 4mb, but you can't zoom. |
Jul 20 2004 wrote: | now has a zoom feature | http://toktok.sscentral.com/files/swet-0.8.7.tar.gz
Mr Ekted wrote: | I don't know how the Java stuff works, but in Win32 you can keep images as DIB's in memory. That is, you could store them as 8-bit images (1/4 the space) mapped to maybe a web palette if they are larger than 1024x1024. Blit time is a little more CPU intensive, but it's a nice speed/size tradeoff. | I guess that's why in a lot of older games each object looks like it has a 256 color palette but the whole screen/viewing area is 16/32bit (or maybe the texture artist had issues).
Grelminar wrote: | I'd like some input on what sorts of regions people want to make, and what they want to use them for | How about toggling certain lvz objects on or off when entering/leaving regions? (although as I read else where you said fancy stuff could be done by 3rd party modules).
This would help the rNAW chunks, you could toggle some text near where it displays the kill messages saying 'anti-warp disabled' or something.
CypherJF wrote: | If you use the BMP, it only allows 1-layer essentially so the region's couldn't overlap, right? :/ | Not if you increment the color indices in such a way that you can mix them. Much like bit fields.
2dragons wrote: | i was messing around with the idea of seeing what java could do in terms of an SS client while viewing elim in TW in Full-Screen Exclusive Mode. | Have you tried speccing a basewar in a zone that has more weapons flying around than TW?
CypherJF wrote: | Nah, LVL's in themselves aren't that huge of a problem size wise, unless they make a full map, with a ton of tiles. LVZ's get big because of WAV and the usage of BMP's still. | If you go into battlezone the lvl is like 450k, meh. |
|
Back to top |
|
|
CypherJF I gargle nitroglycerin
Gender: Joined: Aug 14 2003 Posts: 2582 Location: USA Offline
|
Posted: Thu Aug 12, 2004 7:14 pm Post subject: |
|
|
|
|
The battlezone is an exception |
|
Back to top |
|
|
-Smong- Guest
Offline
|
Posted: Fri Aug 13, 2004 1:58 pm Post subject: |
|
|
|
|
I used this command '../unrar/unrar e ./clit.rar', so where do all the files go? I made a directory called include and put the bm2's in it. BTW, I don't recommend 7-Zip as it has a weird interface and it messes with your right-click menu.
Can't you put all the source in the .jar like what I do with my app's? Or is that against convention or something? |
|
Back to top |
|
|
-Smong- Guest
Offline
|
Posted: Fri Aug 13, 2004 2:12 pm Post subject: |
|
|
|
|
After some much risk assement I went for unrar x clit.rar and hoped it wouldn't trash any system files. For anyone that uses emelfm here is what I added:
unrar in other panel (dodgy)
x cd %D; unrar x %d/%f
View Contents
x unrar vb %f | less
I notice when you delete a region, then add a new one the colour doesn't increment correctly (fx: it stays green until you add yet another region). |
|
Back to top |
|
|
|