Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

DarkknightXC

Members
  • Content count

    121
  • Joined

  • Last visited

About DarkknightXC

  • Rank
    Junior Member
  1. DarkknightXC

    32-Bit Map Format Proposal

    Yeah and the reason for that is the amount of time being spent on trying to get a spec 100% right first time. This is a common problem with open source/community based projects and in fact any project that has no deadline. Deadlines are often a pain up the arse, but OTOH they have the benefit of getting people to make a decision. I think that we can agree on the essential data required to fulfil the requirements of a 32-Bit map format and someone with the avaiable time - the other element in short supply for this type of project - should get knuckle down and just get on with coding up in their respective engine. I don't care what format the data is, so long as the content is there. It can revised later. Nobody here will ever be a 100% happy with the final result. So lets avoid that trap and get on with the business of producing something. I'd rather effort was wasted doing too much then doing nothing but talk for all eternity. Lets get moving and get this back on track.
  2. DarkknightXC

    32-Bit Map Format Proposal

    Got to start somewhere. Work out what we can for ourselves. Forward on to editor developers for feedback. Port authors can construct our own data for testing so we can prove our idea and give the editor developers something to work with when further developing the spec.
  3. DarkknightXC

    32-Bit Map Format Proposal

    Apologies if I've misdirected any praise/abuse (delete as appropriate). I support this effort as a whole and still want a room with a view :).
  4. DarkknightXC

    32-Bit Map Format Proposal

    I see what you are saying, but Graf is doing the right thing by developing a specification in the public domain. Ultimately it is his decision what goes into the specification and it remains to the port authors as to whether they choose to implement it. In the same way that ajapted established a standard for nodes built for GL renderers, Graf is doing the same for an extended map format. We should support him in that process and I do not think there is a better way of doing this apart from sticking every port/editor author on a plane to his location, hiring out one hotel and a conference centre for us all. (Should Graf want to do the conference I'll have a room with a view please :).
  5. DarkknightXC

    32-Bit Map Format Proposal

    Anyone else image of some grey bearded bloke thumping the ground with a staff and the earth shaking. OK, just me then.... (Ok yeah, Mapname restriction works for me).
  6. DarkknightXC

    32-Bit Map Format Proposal

    I Agree. Just not sure on what :).
  7. DarkknightXC

    32-Bit Map Format Proposal

    True. My issue is that the spec should not be vague on such matters. Either exclude the possibility of 8 character names or handle it without possiblity of error (IMHO).
  8. DarkknightXC

    32-Bit Map Format Proposal

    I'm now confused. Why does a mapper care about the naming of their map within a WAD? So long as the application - be it editor or engine - knows where to source the data then the mapper should not have reason to care. I'm not fussed in how you its done - be it by mapname restriction or by remapping lump etc.. - but I would suggest that allowing for a known problem to exist in a spec, makes the spec bad. Having thought about it, only new maps will support this use this format so a limitation on the length of mapname is a simple answer.
  9. DarkknightXC

    32-Bit Map Format Proposal

    It is possible to use 8 characters at the present time and it seems something of a backward step to not support that in the new spec. Rehashing a non-standard mapname is open to error. I think the spec should not define something that is quite so open to error as this. Therefore I am providing a way of working around that. Should we choose to restrict name length I think it preferable to restrict the format of the name also. Say MAPXX in all cases. Fudges - especially those in specs - rarely result in a good working solution. I suppose one could argue that the limitation of the wad format is at fault here and we could write a new one..... ;)
  10. DarkknightXC

    32-Bit Map Format Proposal

    The extradata <-> map data association works if the mapname is a standard MAPXX format. The aliasing of non-standard names to the standard format means that the method of assocation is easy and unbroken. Its up to application to refer to the aliasing lump to get the proper standard mapname from the non-standard mapname. I think its best to solve the non-standard mapname problem as part of the spec as a whole.
  11. DarkknightXC

    32-Bit Map Format Proposal

    I think we've trying to solve the wrong problem here. Rehashing an extended name has the problem of handling where two or more names clash. Perhaps we should have an alias mapname lump, so that all these custom names are remapping to a standard format. We shouldn't care so long as the name is unique in relation to other mapnames.
  12. DarkknightXC

    32-Bit Map Format Proposal

    The major reason I suggested a hex number for the colour format is simple. You can parse it with the standard format specifier.
  13. DarkknightXC

    32-Bit Map Format Proposal

    Work for me, although I would prefer for colour number format to be start with a '0x' to represent the hex format used. Gets around the '#' comment problem.
  14. DarkknightXC

    32-Bit Map Format Proposal

    Ultimately, that is an implementation issue. ACS is one of many which would use such data. I think its makes sense for references to be strings for the reasons stated. Don't beat around the bush, do you? I'm making a suggestion, not writing gospel. No need to be quite some combative in your language. I think that record sizes should be fixed, so data maybe read as a block. Its more efficent and easier to navigate. I applaud the acceptance of implementation specific data, but I would have it positioned after the block of standard implementation data. The suggestion made was a potential solution. How would you tackle this problem? Fair point. I certainly not against text format maps - its just another parser to write that is all.
  15. DarkknightXC

    EDGE Stability

    Agreed. Best to fix the bug in I_MUSStop and then handle the standard exceptions. Suggest to Joe that he disables music with '-nomusic'.
×