Jump to content

Photo

2018 Contest Chat


87 replies to this topic

#26 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Fri Jan 26, 2018 3:12 PM

T-2



#27 Tarzilla OFFLINE  

Tarzilla

    River Patroller

  • 2,066 posts
  • Huh?
  • Location:Alberta, Canada

Posted Fri Jan 26, 2018 3:32 PM

T-2

One of my top 10 favorite movies...



#28 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,564 posts

Posted Sat Jan 27, 2018 12:54 AM

T-2

Dang it, you sunk my battleship. :(



#29 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Sat Jan 27, 2018 1:51 PM

T-1



#30 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Sun Jan 28, 2018 9:11 AM

Launch start!!! :grin:

#31 digress OFFLINE  

digress

    Stargunner

  • 1,017 posts
  • Location:Toronto, Ontario, Canada

Posted Fri Feb 2, 2018 9:06 AM

hmmm. I'm working on a coleco project at the moment but I was considering returning to that inty basic mr turtle game afterwards. Would you consider that eligible since I started it a while ago. Might motivate me to finish it.



#32 carlsson OFFLINE  

carlsson

    Metagalactic Mule

  • 7,084 posts
  • Location:Västerås, Sweden

Posted Fri Feb 2, 2018 9:22 AM

The rules say:

 

The games submitted do not necessarily need to be new, but must be your own work, not sold commercially or released in cartridge format previously.

 

I take that as even somewhat unfinished entries from the 2015 competition may qualify in improved versions for the 2018 competition, plus other projects previously disclosed outside of competition. Though I'd wait for the judges to weigh in on that.



#33 Tarzilla OFFLINE  

Tarzilla

    River Patroller

  • 2,066 posts
  • Huh?
  • Location:Alberta, Canada

Posted Fri Feb 2, 2018 9:58 AM

hmmm. I'm working on a coleco project at the moment but I was considering returning to that inty basic mr turtle game afterwards. Would you consider that eligible since I started it a while ago. Might motivate me to finish it.


Yes, Inty Mr Turtle would be eligible, finish that sucker ;)

#34 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Fri Feb 2, 2018 10:55 AM

Yes, Inty Mr Turtle would be eligible, finish that sucker ;)


What he said but changing sucker to cool thing 8)

#35 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 10,865 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Tue Feb 27, 2018 4:42 AM

I have a question regarding the rule of no ASM.  I see that nanochess suggested to artrag that he could access internal music tracker memory structures via "PEEK" as a work around.

 

Should we really allow this?

 

My understanding was that the "no assembly" rule was to ensure that people were using IntyBASIC for programming, and that means only IntyBASIC features.  If something is not exposed by IntyBASIC and a program tries to use it, then it's really not an IntyBASIC program, isn't it?

 

Consider this extreme example just to illustrate my point:  What if I write a game in pure Assembly Language, assemble then disassemble it, convert it all into DATA statements and loaded it to RAM then trick the IntyBASIC runtime into directing control to it instead?  Would that be an acceptable IntyBASIC program?

 

(I guess that wouldn't be easy to do, but I can't imagine it being impossible.  I think it may be possible to create a "bootstrap" routine that could be overlaid on an IntyBASIC built-in routine via POKEing a bank-switch, then induce IntyBASIC into executing it.  Or even easier:  POKE the bootstrap into the ISR vector and hijack the runtime from the start...)

 

It's an exaggerated and silly example, but where do we draw the line on what is and isn't IntyBASIC?  My suggestion is that it should be clear:  Use only IntyBASIC statements, variables, constants, and other language-exposed facilities.  PEEK and POKE should be constrained to access user-accessible memory.

 

    -dZ.



#36 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Tue Feb 27, 2018 6:30 PM

I have a question regarding the rule of no ASM.  I see that nanochess suggested to artrag that he could access internal music tracker memory structures via "PEEK" as a work around.
 
Should we really allow this?
 
My understanding was that the "no assembly" rule was to ensure that people were using IntyBASIC for programming, and that means only IntyBASIC features.  If something is not exposed by IntyBASIC and a program tries to use it, then it's really not an IntyBASIC program, isn't it?
 
Consider this extreme example just to illustrate my point:  What if I write a game in pure Assembly Language, assemble then disassemble it, convert it all into DATA statements and loaded it to RAM then trick the IntyBASIC runtime into directing control to it instead?  Would that be an acceptable IntyBASIC program?
 
(I guess that wouldn't be easy to do, but I can't imagine it being impossible.  I think it may be possible to create a "bootstrap" routine that could be overlaid on an IntyBASIC built-in routine via POKEing a bank-switch, then induce IntyBASIC into executing it.  Or even easier:  POKE the bootstrap into the ISR vector and hijack the runtime from the start...)
 
It's an exaggerated and silly example, but where do we draw the line on what is and isn't IntyBASIC?  My suggestion is that it should be clear:  Use only IntyBASIC statements, variables, constants, and other language-exposed facilities.  PEEK and POKE should be constrained to access user-accessible memory.
 
    -dZ.


When ARTRAG asked it, I just noted the rules doesn't disallow POKE and PEEK.

Given the rules are now published, it would be unfair to change them as contest develops.

Edit: but not assembly language statements are allowed, that is anything tried to be hidden under DATA or any methods ;)

#37 carlsson OFFLINE  

carlsson

    Metagalactic Mule

  • 7,084 posts
  • Location:Västerås, Sweden

Posted Wed Feb 28, 2018 2:45 AM

POKE is fun. Yesterday I noticed that if you "drift away" from the BACKTAB with your variables holding a memory address, you can create all kinds of interesting sounds by POKEing in the wrong place. At least in jzintv. :)



#38 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 10,865 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Wed Feb 28, 2018 4:07 AM

When ARTRAG asked it, I just noted the rules doesn't disallow POKE and PEEK.

Given the rules are now published, it would be unfair to change them as contest develops.

Edit: but not assembly language statements are allowed, that is anything tried to be hidden under DATA or any methods ;)

 

Or... we could clarify the spirit of the rules of the contest.  I do not think we need to be explicit in the rules about something like this.  It should be clear that if there is no variable exposed for it, and no IntyBASIC mechanism to do it, it is not allowed.

 

No, PEEK and POKE are not disallowed, that's not the problem.  They can be used to access the published memory map.  The fact that he has to assemble, then read the "listing" file in order to get the memory location is also a red flag that goes against the spirit of the contest.

 

Personally I would disallow that out of principle.  No reasonable person would even suggest that that is an "IntyBASIC" feature.

 

   -dZ.



#39 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Wed Feb 28, 2018 9:56 AM

 
Or... we could clarify the spirit of the rules of the contest.  I do not think we need to be explicit in the rules about something like this.  It should be clear that if there is no variable exposed for it, and no IntyBASIC mechanism to do it, it is not allowed.
 
No, PEEK and POKE are not disallowed, that's not the problem.  They can be used to access the published memory map.  The fact that he has to assemble, then read the "listing" file in order to get the memory location is also a red flag that goes against the spirit of the contest.
 
Personally I would disallow that out of principle.  No reasonable person would even suggest that that is an "IntyBASIC" feature.
 
   -dZ.


I'll suggest him to use a variable to keep the unreadable status.

Other than that I don't want to change rules during contest.

#40 artrag ONLINE  

artrag

    Stargunner

  • 1,020 posts

Posted Wed Feb 28, 2018 1:43 PM

DZ I think the spirit of the contest is to spread knowledge of the intellivision and promote the coding of new games for this funny ancient console, while the spirit of the rule that does not allow assembly is to make a common playfield among all the potential concurrent. But the spirit, as a such, is not a written rule and anyone could easily misinterpret it, as I think you could have done. So why not to stick to plain rules that say that the game has to be compiled with Intybasic v.1.2.9 and not include hand written ASM code? 



#41 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,564 posts

Posted Wed Feb 28, 2018 6:07 PM

I use PEEK and POKE to get the value of the screen data to do my sprite to tile collision.  So those 2 functions should be allowed.



#42 Tarzilla OFFLINE  

Tarzilla

    River Patroller

  • 2,066 posts
  • Huh?
  • Location:Alberta, Canada

Posted Wed Feb 28, 2018 6:27 PM

I use PEEK and POKE to get the value of the screen data to do my sprite to tile collision.  So those 2 functions should be allowed.

Yes peek and poke should be allowed as they are available in the language. Helper ASM is disallowed, no matter how creative the programmer tries to be. There are multiple programmers on the judging committee and we will have access to the code since one of the stipulations is someone on the judging panel has to built it from source to replicate the submitted binary.

I think these two parts covers it:

"Your game(s) must be developed in IntyBASIC v1.2.9 and use the default prologue/epilogue files. The assembly language statements allowed within your game are the ORG statement so that you can develop a larger game and the CFGVAR statement to introduce metadata. "

"As part of the validation process, each entry's source code will be built using its instructions and the final binary produced must match the submitted binary image 100%. Any entry that fails this criteria will not be judged."

#43 artrag ONLINE  

artrag

    Stargunner

  • 1,020 posts

Posted Thu Mar 1, 2018 6:31 AM

When I say hand written asm I mean code written by the author of the submitted game, no matter if he is generating code with other tools or tricks.
The rule is needed to not give advantage to asm coders vs newcomers.
Apart from that, exploiting intybasic and its environment should be allowed if not welcome.
About compatibility with future versions of intybasic, it is not in the rules, but it will be my cure to update the sources or return any prize eventually won in case the game does not compile and run properly with the next intybasic releases.

Edited by artrag, Thu Mar 1, 2018 7:21 AM.


#44 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 10,865 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Thu Mar 1, 2018 6:39 AM

I use PEEK and POKE to get the value of the screen data to do my sprite to tile collision.  So those 2 functions should be allowed.

 
 
Of course! From my comment:

No, PEEK and POKE are not disallowed, that's not the problem.  They can be used to access the published memory map.

 

It's not the act of using PEEK and POKE that I thought should be disallowed, but the access to memory and data not exposed by either the known peripheral memory map or exposed by IntyBASIC.  It is my opinion that direct manipulation of private variables used internally by IntyBASIC's runtime is an unwarranted advantage over someone who just uses stock IntyBASIC.

 

   -dZ.



#45 artrag ONLINE  

artrag

    Stargunner

  • 1,020 posts

Posted Thu Mar 1, 2018 7:34 AM

The sole reason to disallow the access to the intybasic working ram is the potential compatibility with next versions of the compiler. That is not in the rules.
Provided that the compiler version is strictly defined by the rules themselves and that the goal of the competition is to spread the knowledge and the interest for the console, giving to non asm coders equal opportunity to asm coders, I do not see your point. Unless you are just trolling for the fun of it.

#46 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 10,865 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Thu Mar 1, 2018 7:56 AM

The sole reason to disallow the access to the intybasic working ram is the potential compatibility with next versions of the compiler. That is not in the rules.
Provided that the compiler version is strictly defined by the rules themselves and that the goal of the competition is to spread the knowledge and the interest for the console, giving to non asm coders equal opportunity to asm coders, I do not see your point. Unless you are just trolling for the fun of it.

 

Thank you for making this personal.  Up until this point, various people have expressed their opinions, as did I.

 

I disagree with you that the "sole reason to disallow the access to IntyBASIC working ram is the potential compatibility with next version of the compiler."  In my opinion, and based on discussions we've had since last year's contest, the reason is to level the playing field by forcing everyone to use the same version of IntyBASIC and only IntyBASIC facilities.

 

I still assert that accessing internal private variables of the runtime goes against this, but that is just my opinion.  I also assert that this is enshrined in the phrasing of this rule:

 

 

Your game(s) must be developed in IntyBASIC v1.2.9 and use the default prologue/epilogue files. The assembly language statements allowed within your game are the ORG statement so that you can develop a larger game and the CFGVAR statement to introduce metadata. However, bank switching is not permitted.

 

I accept that it does not say this specifically, but it also does not say that you cannot enhance the prologue/epilogue files or expand them, just that you must use the default ones.  No reasonable person would suggest that it should also explicitly state "you must use the default prologue/epilogue files without modifications," and that without that last part there is a loophole.  The same with this issue.

 

In every contest there is always a discretion of the judges to apply the rules as they best understand them.  Oscar has already stated he believes the rules do not apply this point, and so I was trying to explain to him why I believe they do.  Why is that trolling?

 

I never suggested that you were trying to cheat or find loopholes in the rules, I merely pointed out that Oscar was offering a suggestion for an enhancement that I thought went against the rules and that we shouldn't allow it.  That is all.

 

Now I ask to everyone, will it really be so bad if people were not allowed to access private variables of the runtime by obtaining their values from the compiled assembly listing?  I believe that the worst case scenario is that it prevents people from using a feature or performing a function that the stock IntyBASIC does not already provide -- which is par for the course for anybody using IntyBASIC, newbies and veterans.  And that, in my opinion, is what the rules are trying to establish.  Others may disagree.

 

    -dZ.



#47 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Thu Mar 1, 2018 10:17 AM

The sole reason to disallow the access to the intybasic working ram is the potential compatibility with next versions of the compiler. That is not in the rules.
Provided that the compiler version is strictly defined by the rules themselves and that the goal of the competition is to spread the knowledge and the interest for the console, giving to non asm coders equal opportunity to asm coders, I do not see your point. Unless you are just trolling for the fun of it.

 

Thank you for making this personal.  Up until this point, various people have expressed their opinions, as did I.


Both of you please don't make it personal.

It's my fault to not make rules more strict, it's allowed by the rules this year, although not recommended, but I'll make sure next year the rules are stricter.

It's up to ARTRAG if he wants to run by the side of rules, but I've recommended him to not.

Nothing to see here, let us go back to developing games :)

#48 carlsson OFFLINE  

carlsson

    Metagalactic Mule

  • 7,084 posts
  • Location:Västerås, Sweden

Posted Thu Mar 1, 2018 10:39 AM

Yeah. We had Whale Hunt winning the competition last time, no need to make "Jaws: The Revenge" this time around. :)

 

wVU0ntUEoqsoPKzKUPxN5WqRW1R.jpg


Edited by carlsson, Thu Mar 1, 2018 10:42 AM.


#49 fsuinnc OFFLINE  

fsuinnc

    Moonsweeper

  • 475 posts
  • Location:Chapel Hill NC.

Posted Mon Mar 19, 2018 8:15 PM

In the Slalom thread (http://atariage.com/...ry-2015-slalom/) this animation is shown post-38229-0-58342200-1434863941.gif  

 

(not sure how to link straight to the actual post).  Was this done with IntyBasic and if so, is the source code available?

 

if not, anybody got code to explain the basics of how to do this?

 

I am looking to scroll things on different lines at different speeds. possibly with different colors and maybe in different directions. but straight left to right and right to left.



#50 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,423 posts
  • Coding something good
  • Location:Mexico City

Posted Mon Mar 19, 2018 8:55 PM

In the Slalom thread (http://atariage.com/...ry-2015-slalom/) this animation is shown  post-38229-0-58342200-1434863941.gif 
 
(not sure how to link straight to the actual post).  Was this done with IntyBasic and if so, is the source code available?
 
if not, anybody got code to explain the basics of how to do this?
 
I am looking to scroll things on different lines at different speeds. possibly with different colors and maybe in different directions. but straight left to right and right to left.

Given the number of objects in screen at same time, this is done with 16 GRAM predefined.

The object is moved one bit to right for 8 times, the extra goes into another card.

Then you use an array to select the card for the pixel coordinate AND 7.

Essentially infinite objects of same type on screen.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users