Page 4 of 6

Posted: Tue Nov 02, 2010 3:01 am
by thefox
65024U wrote:Sorry if I sounded like that, but depending on such items to be on a users PC is probably a bad idea (and makes me mad because M$ makes crap software)
Ehhh? So it's Microsoft's fault that people don't ship the necessary libraries with their program? AFAIK VB6 even comes with an installer builder that can automatically detect the dependencies.

Posted: Tue Nov 02, 2010 5:35 am
by Bregalad
never-obsolete wrote: I got to thinking about pointers to screens/rows in compressed maps. How would you relay the starting and stopping points to the assembler?
I'm really sorry but I don't understand your question.

Posted: Tue Nov 02, 2010 6:07 am
by tepples
In a compressed map that is decompressed screen-by-screen rather than whole-thing-to-WRAM, there needs to be some way for the program to quickly find each page as the camera enters it.

Posted: Tue Nov 02, 2010 6:13 am
by Bregalad
Yeah, therefore my point of having it compressed screen by screen (or row by row in the case of an area type map) and have a pointer on each screen/row.

Posted: Tue Nov 02, 2010 8:29 am
by 3gengames
I was thinking about it too a while ago. IMO, It seemed just to make one whole map that was lets say 255x255. Then have the RLE compression for each row be in a array of RAM that kept track how many in X place are done out of the RLE repeat byte. I know it's wasteful, but it seems the easiest way to me. :/



And yeah, so? Nobody needs Microsofts binaries for anything, theres more then one graphics library out there. 0_o

Posted: Tue Nov 02, 2010 2:35 pm
by Banshaku
65024U wrote:And yeah, so? Nobody needs Microsofts binaries for anything, theres more then one graphics library out there. 0_o
Let's explain it another way. If you make an application in Java, you need the java runtime (JRE), right? Another example, if you make an application in .net, you need the .net runtime (.net framework), right?

If you follow where I'm going, if you make an application in VB6, it does require a runtime, the VB6 runtime libraries. It's not a graphic library, it's the runtime to make the application run.

As for graphic library, many of them will require some dll to be delivered with the application.

So the point is, if you don't deliver with your application the required runtime or library or don't explain which one is required for you to download, it will be hard to use the application isn't it? So I'm not sure what your point is about.

Posted: Tue Nov 02, 2010 7:00 pm
by 3gengames
Okay I am following you now, but something that would just be plain C and a graphics library that works in Mac and Linux would even better. :D But oh well, I guess mac users are out of luck. :/

Posted: Tue Nov 02, 2010 8:36 pm
by clueless
65024U wrote:Okay I am following you now, but something that would just be plain C and a graphics library that works in Mac and Linux would even better. :D But oh well, I guess mac users are out of luck. :/
I would expect "wine" to work on an Intel based Mac. I have never tried it though. My Mac is a Mac LC-II running system 7.5.3 with an Apple IIe card (although I can swap that for a 10mbit ethernet card).

http://www.winehq.org/

Posted: Wed Dec 22, 2010 9:28 am
by Yggi
Ever heard of "Jabaco"? It's a (free) Basic programming language which is almost full compatible to Visual Basic 6.0 (a few changes are needed afaik), but compiles your code to java-byte-code, so it works on a lot of operating systems... :)

btw, hello. i'm new to nesdev :D

Posted: Wed Dec 22, 2010 10:53 am
by 3gengames
Welcome! :D


Java? Interesting...

Re: Tool: MapEd Pro

Posted: Sat Sep 22, 2012 12:40 pm
by infiniteneslives
The downloads appear to be broken... Does someone have a copy to repost, or fix the original link?

Re: Tool: MapEd Pro

Posted: Sun Sep 23, 2012 8:18 am
by never-obsolete
Hmmm...the host must be down again. I'll upload it somewhere else this evening when I get home from work.

Re: Tool: MapEd Pro

Posted: Sat Sep 29, 2012 2:19 pm
by never-obsolete
Sorry for the delay. Here's an updated version and the changes are:

-edit/import palette definitions (*.pal files used by emulators)
-"wide" view for laptops
-pointers to rows/columns/screens when compressing map data
-some RLE variations (thanks Bregalad)
-some bug fixes

When you compress map data in blocks, the editor spits out another file (*.mpt) with a list of pointers in this format:

Code: Select all

	.dw $_ptr + #
where '$' is the map file title and '#' is an offset into the map data. In theory, it supposed to work like this:

"main.asm":

Code: Select all


; main pointer table to each list of pointers
mapdata_ptrlo:	.db <m00_blkptrs
mapdata_ptrhi:	.db >m00_blkptrs

; pointers to each "block" of data
m00_blkptrs:	.include "map00.mpt"

; the actual map data
map00_ptr:	.incbin "map00.map"
"map00.mpt":

Code: Select all

	.dw map00_ptr + 0
	.dw map00_ptr + 4
	.dw map00_ptr + 11
	; etc...
The goal was to be able to edit your maps without having to make changes to pointers or code.

edit: see first post for link

Re: Tool: MapEd Pro

Posted: Sat Sep 29, 2012 3:33 pm
by Hamtaro126
My Screen Resolution is too small to use the map editor (1366x768 Laptop screen), Can you do some adjustments for use at least in 1024x600 res or at least let the user choose resolution settings?

EDIT: I Must Read before talking... Sorry!

Re: Tool: MapEd Pro

Posted: Sat Sep 29, 2012 4:07 pm
by infiniteneslives
Thanks for relinking this and the updates!