Why restrict it to a single byte if it's possible to increase it? It's not like anyone is going to DISLIKE the fact that it wouldn't be a limitation.
| Ryandor.com http://www.ryandor.com/forum/ |
|
| How much of a limitation is the fact altitude is a byte. http://www.ryandor.com/forum/viewtopic.php?f=4&t=2912 |
Page 1 of 1 |
| Author: | punt1959 [ Fri Jun 09, 2006 2:17 pm ] |
| Post subject: | How much of a limitation is the fact altitude is a byte. |
There appears to be a slight interest in a client/server by at least one other Developer (Raged). Given the desire to work on different OS's, and languages, we have decided to share information and work to a common data format. We hope to capitlize on the fact we have another person who is tackling the same problem for solutions, if not the same code. We hope that will keep intersest in what promieses to be a mammoth task, while still giving the freedom needed to pursue ones favorite OS/language. Now, we still plan to intially populate the data sets based on UO (so the client will be needed for data population), to allow us to focus on the coding aspect. However, the data formats will be modified, as we are focussing on data that we understand, in formats we think are easiest for us. Hopefully this will result in some simplification in the process. I believe we have an approach for most of the the data types (graphics,tile information, messages). We are currently looking at the map. The concept is to be similar to the original UO client, so it is isometric. Was wondering if the altitude being only a byte was a major limitation? So, here I am , asking the map making portal for UO! |
|
| Author: | Stormcrow [ Fri Jun 09, 2006 3:01 pm ] |
| Post subject: | |
It might be if you had a true 3d client but with the isometric, no. |
|
| Author: | punt1959 [ Fri Jun 09, 2006 6:13 pm ] |
| Post subject: | Thanks! |
Good to know! I will probably only support a single map intially. This will look very muck like the original UO in terms of type of data support. |
|
| Author: | Xuri [ Fri Jun 09, 2006 7:08 pm ] |
| Post subject: | |
Why restrict it to a single byte if it's possible to increase it? It's not like anyone is going to DISLIKE the fact that it wouldn't be a limitation.
|
|
| Author: | punt1959 [ Fri Jun 09, 2006 7:17 pm ] |
| Post subject: | |
True, but it of course everything is a trade off. The extra byte per cell, increases the disk space, memory utilization, and load time whenver the block is read in. So trying to determine if it really brings enough to the table! |
|
| Author: | Sydius [ Fri Jun 09, 2006 7:46 pm ] |
| Post subject: | |
Store the map in compressed chunks (like blocks in the current format, but slightly bigger), and read it in as you need it. Smaller disk size at the price of runtime read speed, but that is so negligible that it should not be a concern unless you hope to support decade-old (or small/cheap laptop) computers. |
|
| Author: | punt1959 [ Fri Jun 09, 2006 8:18 pm ] |
| Post subject: | |
Well, yea, but again, the goal is to also simplify the job. I am well aware of the mountain of work facing myself (from my perspective), as well as my own limitations. So at this stage, elimination and simplification, that results in less for myself to do/code/learn is what I am striving for. As for ancient, I am hoping to have it peform on some modest hardware (some of the older iBooks at least). Raged may be planning for something more powerful (given C#/DX9) cpu wise. We both are looking to keep memory footprints to about 100MB for the client. Server, we haven't discussed its footprint. But file compression is something to consider |
|
| Page 1 of 1 | All times are UTC - 7 hours [ DST ] |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|